Marco Shoal: cómo Soltar la latencia de Bullshark en Aptos
Aptos Labs recientemente resolvió dos importantes problemas abiertos en DAG BFT, lo que redujo significativamente la latencia y eliminó por primera vez la necesidad de tiempos de espera en protocolos de consenso deterministas. 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 cualquier protocolo de consenso basado en Narwhal ( como DAG-Rider, Tusk, Bullshark ) a través de tuberías y reputación de líderes. La tubería reduce la latencia de ordenación de DAG al introducir un punto de anclaje en cada ronda, y la 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 que Shoal utilice construcciones de DAG asíncronas para eliminar los tiempos de espera en todos los escenarios. Esto permite que Shoal ofrezca una propiedad llamada respuesta universal, que contiene la respuesta optimista que normalmente se requiere.
Esta tecnología es muy sencilla, consiste en ejecutar múltiples instancias del protocolo subyacente una tras otra en secuencia. Por lo tanto, cuando se instancia con Bullshark, se obtiene un grupo de "tiburones" que están en una carrera de relevos.
Fondo
Al perseguir un alto rendimiento en la red 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 rendimiento. Por ejemplo, el Hotstuff implementado en las primeras versiones de Diem solo logró 3500 TPS, muy por debajo del objetivo de 100k+ TPS.
El reciente avance proviene de reconocer que la propagación de datos es el principal cuello de botella basado en el protocolo de los líderes, y que 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 al mismo tiempo, mientras que el componente de consenso solo ordena una pequeña cantidad de metadatos. El documento de Narwhal reporta una capacidad de 160,000 TPS.
En artículos anteriores se presentó Quorum Store, es decir, la implementación de Narwhal que separa la propagación de datos del consenso, así como 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 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 completamente el potencial de rendimiento de Narwhal. A pesar de separar 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, se decidió implementar Bullshark sobre Narwhal DAG, que es un protocolo de consenso con cero costos 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 logra reducir significativamente la latencia de Bullshark.
Fondo de DAG-BFT
Cada vértice en el DAG de Narwhal está asociado a 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 transmitir 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 que no es ambigua: 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 total
Se puede alcanzar consenso sobre el orden total de todos los vértices en el DAG sin el costo de comunicación adicional. 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 predefinido, el pico del líder se llama punto de anclaje;
Puntos de anclaje de orden: los validadores deciden de manera independiente pero determinista qué puntos de anclaje ordenar y cuáles omitir;
Historia de causa y efecto ordenada: los validadores procesan uno a uno su lista de anclajes ordenados y, para cada anclaje, ordenan todos los vértices anteriores desordenados en su historia de causa y efecto mediante algunas 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 todas las listas compartan el mismo prefijo. En Shoal, se hacen las siguientes observaciones sobre todos los protocolos:
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 de Bullshark es más eficiente que la versión asincrónica, todavía está lejos de ser óptima.
Pregunta 1: latencia promedio de bloques. En Bullshark, cada ronda par tiene un ancla, y el vértice de cada ronda impar se interpreta como un voto. En situaciones comunes, se requieren dos rondas de DAG para ordenar el ancla; sin embargo, los vértices en la historia causal del ancla necesitan más rondas para esperar que el ancla sea ordenado. En situaciones comunes, los vértices en rondas impares necesitan tres rondas, mientras que los vértices no ancla en rondas pares necesitan cuatro rondas.
Pregunta 2: latencia de casos de falla, el análisis de latencia anterior se aplica a situaciones sin fallas. Por otro lado, si un líder de ronda no logra difundir suficientemente rápido el ancla, no se puede ordenar el ancla ( y, por lo tanto, se salta ). Por lo tanto, todos los vértices no ordenados en las rondas anteriores deben esperar a que el próximo ancla sea ordenado. Esto disminuye significativamente el rendimiento de la red de replicación geográfica, especialmente porque el tiempo de espera de Bullshark se utiliza para esperar al líder.
Marco de Shoal
Shoal resolvió estos dos problemas de latencia, mejorando Bullshark( o cualquier otro protocolo BFT basado en Narwhal) a través de un pipeline, permitiendo 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 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, la reputación de la línea de producción y del líder se considera un problema difícil por las siguientes razones:
Las líneas de producción anteriores 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 a los futuros líderes en función del rendimiento pasado de los validadores en la idea del ancla en Bullshark (. Aunque la discrepancia en la identidad del líder no viola la seguridad de estos protocolos, en Bullshark, puede llevar a un orden completamente diferente, lo que plantea el núcleo del problema, es decir, 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 seleccionar futuros anclajes.
Como evidencia de la dificultad del problema, la implementación de Bullshark, incluida la que actualmente está en producción, no soporta estas características.
Protocolo
A pesar de los desafíos mencionados, la solución se ha demostrado que está oculta detrás de la simplicidad.
En Shoal, se basa en la capacidad de realizar cálculos locales en el DAG y se implementa la capacidad de guardar y reinterpretar la información de rondas anteriores. Con la intuición central de que todos los validadores acuerdan el primer ancla ordenada, Shoal combina secuencialmente múltiples instancias de Bullshark para procesarlas en una línea de producción, de modo que ) el primer ancla ordenada es el punto de cambio de las instancias, así como ( la historia causal de los anclajes se utiliza para calcular la reputación del líder.
![Explicación detallada del marco Shoal: ¿cómo reducir la latencia de Bullshark en Aptos?])https://img-cdn.gateio.im/webp-social/moments-46d37add0d9e81b2f295edf8eddd907f.webp(
Línea de producción
V que mapea las rondas a los líderes. Shoal ejecuta instancias de Bullshark una tras otra, de modo que para cada instancia, el ancla es 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 estuvieron de acuerdo con 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 que Shoal ordene un ancla en cada ronda. Los puntos de anclaje de la primera ronda se ordenan según la primera instancia. Luego, Shoal inicia una nueva instancia en la segunda ronda, que tiene su propio punto de anclaje, y ese ancla se ordena por esa instancia, luego, otra nueva instancia ordena el punto de anclaje en la tercera ronda, y el proceso continúa.
![Explicación detallada del marco Shoal: ¿cómo Soltar la latencia de Bullshark en Aptos?])https://img-cdn.gateio.im/webp-social/moments-0b0928cb6240e994c1514c75e080a4b2.webp(
Reputación del líder
Durante el período de clasificación de Bullshark, al saltar puntos de anclaje, la latencia aumentará. En este caso, la técnica de canalización es ineficaz, ya que no se puede iniciar una nueva instancia hasta que se haya ordenado el punto de anclaje de la instancia anterior. Shoal asegura que es poco probable que se elija al líder correspondiente para manejar los puntos de anclaje perdidos 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 el uso de un mecanismo de reputación. Los validadores que respondan y participen 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 podrían estar fallando, lentos o actuando maliciosamente.
Su idea es recalcular de manera determinista el mapeo predefinido F desde la ronda hasta el líder cada vez que se actualizan las puntuaciones, favoreciendo a los líderes con puntuaciones más altas. Para que los validadores lleguen a un consenso sobre el nuevo mapeo, deberían llegar a un consenso sobre las puntuaciones, alcanzando así un consenso sobre la historia utilizada para derivar las puntuaciones.
En Shoal, la cadena de bloques y la reputación del liderazgo pueden combinarse de forma natural, ya que ambas 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, basado 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.
![Explicación detallada del marco Shoal: ¿cómo Soltar la latencia de Bullshark en Aptos?])https://img-cdn.gateio.im/webp-social/moments-859e732e16c3eee0e2c93422474debc2.webp(
No hay más tiempo de espera
El tiempo de espera juega un papel crucial en todas las implementaciones BFT deterministas 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 se requiere un ajuste dinámico, ya que depende en gran medida del entorno ) de la red (. Antes de transferirse al siguiente líder, el protocolo pagará una penalización completa por la latencia de tiempo de espera del 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, observamos que, en situaciones de alta carga, los líderes en Jolteon/Hotstuff se ven abrumados y el tiempo de espera ya ha expirado antes de que puedan impulsar el progreso.
Desafortunadamente, los protocolos de líderes ) como Hotstuff y Jolteon ( requieren esencialmente latencia para garantizar que cada vez el líder
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.
El marco Shoal reduce significativamente la latencia de Bullshark en Aptos, mejorando entre un 40% y un 80%.
Marco Shoal: cómo Soltar la latencia de Bullshark en Aptos
Aptos Labs recientemente resolvió dos importantes problemas abiertos en DAG BFT, lo que redujo significativamente la latencia y eliminó por primera vez la necesidad de tiempos de espera en protocolos de consenso deterministas. 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 cualquier protocolo de consenso basado en Narwhal ( como DAG-Rider, Tusk, Bullshark ) a través de tuberías y reputación de líderes. La tubería reduce la latencia de ordenación de DAG al introducir un punto de anclaje en cada ronda, y la 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 que Shoal utilice construcciones de DAG asíncronas para eliminar los tiempos de espera en todos los escenarios. Esto permite que Shoal ofrezca una propiedad llamada respuesta universal, que contiene la respuesta optimista que normalmente se requiere.
Esta tecnología es muy sencilla, consiste en ejecutar múltiples instancias del protocolo subyacente una tras otra en secuencia. Por lo tanto, cuando se instancia con Bullshark, se obtiene un grupo de "tiburones" que están en una carrera de relevos.
Fondo
Al perseguir un alto rendimiento en la red 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 rendimiento. Por ejemplo, el Hotstuff implementado en las primeras versiones de Diem solo logró 3500 TPS, muy por debajo del objetivo de 100k+ TPS.
El reciente avance proviene de reconocer que la propagación de datos es el principal cuello de botella basado en el protocolo de los líderes, y que 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 al mismo tiempo, mientras que el componente de consenso solo ordena una pequeña cantidad de metadatos. El documento de Narwhal reporta una capacidad de 160,000 TPS.
En artículos anteriores se presentó Quorum Store, es decir, la implementación de Narwhal que separa la propagación de datos del consenso, así como 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 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 completamente el potencial de rendimiento de Narwhal. A pesar de separar 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, se decidió implementar Bullshark sobre Narwhal DAG, que es un protocolo de consenso con cero costos 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 logra reducir significativamente la latencia de Bullshark.
Fondo de DAG-BFT
Cada vértice en el DAG de Narwhal está asociado a 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 transmitir 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 que no es ambigua: 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 total
Se puede alcanzar consenso sobre el orden total de todos los vértices en el DAG sin el costo de comunicación adicional. 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 predefinido, el pico del líder se llama punto de anclaje;
Puntos de anclaje de orden: los validadores deciden de manera independiente pero determinista qué puntos de anclaje ordenar y cuáles omitir;
Historia de causa y efecto ordenada: los validadores procesan uno a uno su lista de anclajes ordenados y, para cada anclaje, ordenan todos los vértices anteriores desordenados en su historia de causa y efecto mediante algunas 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 todas las listas compartan el mismo prefijo. En Shoal, se hacen las siguientes observaciones sobre todos los protocolos:
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 de Bullshark es más eficiente que la versión asincrónica, todavía está lejos de ser óptima.
Pregunta 1: latencia promedio de bloques. En Bullshark, cada ronda par tiene un ancla, y el vértice de cada ronda impar se interpreta como un voto. En situaciones comunes, se requieren dos rondas de DAG para ordenar el ancla; sin embargo, los vértices en la historia causal del ancla necesitan más rondas para esperar que el ancla sea ordenado. En situaciones comunes, los vértices en rondas impares necesitan tres rondas, mientras que los vértices no ancla en rondas pares necesitan cuatro rondas.
Pregunta 2: latencia de casos de falla, el análisis de latencia anterior se aplica a situaciones sin fallas. Por otro lado, si un líder de ronda no logra difundir suficientemente rápido el ancla, no se puede ordenar el ancla ( y, por lo tanto, se salta ). Por lo tanto, todos los vértices no ordenados en las rondas anteriores deben esperar a que el próximo ancla sea ordenado. Esto disminuye significativamente el rendimiento de la red de replicación geográfica, especialmente porque el tiempo de espera de Bullshark se utiliza para esperar al líder.
Marco de Shoal
Shoal resolvió estos dos problemas de latencia, mejorando Bullshark( o cualquier otro protocolo BFT basado en Narwhal) a través de un pipeline, permitiendo 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 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, la reputación de la línea de producción y del líder se considera un problema difícil por las siguientes razones:
Las líneas de producción anteriores 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 a los futuros líderes en función del rendimiento pasado de los validadores en la idea del ancla en Bullshark (. Aunque la discrepancia en la identidad del líder no viola la seguridad de estos protocolos, en Bullshark, puede llevar a un orden completamente diferente, lo que plantea el núcleo del problema, es decir, 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 seleccionar futuros anclajes.
Como evidencia de la dificultad del problema, la implementación de Bullshark, incluida la que actualmente está en producción, no soporta estas características.
Protocolo
A pesar de los desafíos mencionados, la solución se ha demostrado que está oculta detrás de la simplicidad.
En Shoal, se basa en la capacidad de realizar cálculos locales en el DAG y se implementa la capacidad de guardar y reinterpretar la información de rondas anteriores. Con la intuición central de que todos los validadores acuerdan el primer ancla ordenada, Shoal combina secuencialmente múltiples instancias de Bullshark para procesarlas en una línea de producción, de modo que ) el primer ancla ordenada es el punto de cambio de las instancias, así como ( la historia causal de los anclajes se utiliza para calcular la reputación del líder.
![Explicación detallada del marco Shoal: ¿cómo reducir la latencia de Bullshark en Aptos?])https://img-cdn.gateio.im/webp-social/moments-46d37add0d9e81b2f295edf8eddd907f.webp(
Línea de producción
V que mapea las rondas a los líderes. Shoal ejecuta instancias de Bullshark una tras otra, de modo que para cada instancia, el ancla es 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 estuvieron de acuerdo con 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 que Shoal ordene un ancla en cada ronda. Los puntos de anclaje de la primera ronda se ordenan según la primera instancia. Luego, Shoal inicia una nueva instancia en la segunda ronda, que tiene su propio punto de anclaje, y ese ancla se ordena por esa instancia, luego, otra nueva instancia ordena el punto de anclaje en la tercera ronda, y el proceso continúa.
![Explicación detallada del marco Shoal: ¿cómo Soltar la latencia de Bullshark en Aptos?])https://img-cdn.gateio.im/webp-social/moments-0b0928cb6240e994c1514c75e080a4b2.webp(
Reputación del líder
Durante el período de clasificación de Bullshark, al saltar puntos de anclaje, la latencia aumentará. En este caso, la técnica de canalización es ineficaz, ya que no se puede iniciar una nueva instancia hasta que se haya ordenado el punto de anclaje de la instancia anterior. Shoal asegura que es poco probable que se elija al líder correspondiente para manejar los puntos de anclaje perdidos 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 el uso de un mecanismo de reputación. Los validadores que respondan y participen 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 podrían estar fallando, lentos o actuando maliciosamente.
Su idea es recalcular de manera determinista el mapeo predefinido F desde la ronda hasta el líder cada vez que se actualizan las puntuaciones, favoreciendo a los líderes con puntuaciones más altas. Para que los validadores lleguen a un consenso sobre el nuevo mapeo, deberían llegar a un consenso sobre las puntuaciones, alcanzando así un consenso sobre la historia utilizada para derivar las puntuaciones.
En Shoal, la cadena de bloques y la reputación del liderazgo pueden combinarse de forma natural, ya que ambas 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, basado 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.
![Explicación detallada del marco Shoal: ¿cómo Soltar la latencia de Bullshark en Aptos?])https://img-cdn.gateio.im/webp-social/moments-859e732e16c3eee0e2c93422474debc2.webp(
No hay más tiempo de espera
El tiempo de espera juega un papel crucial en todas las implementaciones BFT deterministas 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 se requiere un ajuste dinámico, ya que depende en gran medida del entorno ) de la red (. Antes de transferirse al siguiente líder, el protocolo pagará una penalización completa por la latencia de tiempo de espera del 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, observamos que, en situaciones de alta carga, los líderes en Jolteon/Hotstuff se ven abrumados y el tiempo de espera ya ha expirado antes de que puedan impulsar el progreso.
Desafortunadamente, los protocolos de líderes ) como Hotstuff y Jolteon ( requieren esencialmente latencia para garantizar que cada vez el líder