Marco Shoal: Reducción significativa de la latencia de Bullshark en Aptos
Resumen
Aptos labs resolvió dos importantes problemas abiertos en DAG BFT, reduciendo significativamente la latencia y eliminando por primera vez la necesidad de tiempos de espera en protocolos prácticos 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 a través de la canalización y la reputación de los líderes. La canalización reduce la latencia de ordenamiento de DAG al introducir un ancla en cada ronda, y la reputación de los líderes mejora aún más el problema de latencia al garantizar que el ancla esté asociada con los nodos de validación más rápidos. Además, la reputación de los líderes permite que Shoal utilice construcciones DAG asíncronas para eliminar los tiempos de espera en todos los escenarios. Esto permite que Shoal proporcione atributos de respuesta universal, que incluyen la respuesta optimista que normalmente se requiere.
Esta tecnología es muy simple, implica ejecutar múltiples instancias del protocolo subyacente en secuencia. Por lo tanto, cuando se instancia con Bullshark, obtenemos un grupo de "tiburones" que están participando en una carrera de relevos.
Motivación
Al buscar un alto rendimiento en las redes blockchain, las personas han estado enfocándose en reducir la complejidad de la comunicación. Sin embargo, este enfoque no ha llevado a un aumento significativo en el rendimiento. Por ejemplo, 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 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, 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.
Antes presentamos Quorum Store, nuestra implementación de Narwhal que separa la propagación de datos de la consensus, 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 al estilo PBFT, reduciendo 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 de la consensus, a medida que aumenta el rendimiento, el líder de Hotstuff/Jolteon sigue estando limitado.
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 el alto rendimiento de Bullshark trae un costo de latencia del 50%.
Este artículo presenta cómo Shoal logra reducir significativamente la latencia de Bullshark.
Contexto de DAG-BFT
Cada vértice en el DAG de Narwhal está asociado con una 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 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 de DAG no es ambigua: 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 llegar a un consenso sobre el orden total de todos los vértices en el DAG sin costos 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 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: cada pocas rondas hay un líder predeterminado, el vértice del líder se llama punto de anclaje;
Puntos de anclaje de pedido: los validadores deciden de manera independiente pero determinista qué puntos de anclaje pedir y cuáles omitir;
Historial causal de pedidos: los validadores procesan uno por uno la lista de anclajes ordenados y ordenan todos los vértices desordenados anteriores en el historial causal de cada anclaje.
La clave para cumplir con 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 acuerdan el primer punto de anclaje ordenado.
Bullshark latencia
La latencia de Bullshark depende del número de rondas entre los anclajes 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, está lejos de ser la óptima.
Pregunta 1: Latencia promedio de bloques. En Bullshark, cada ronda par tiene un ancla, y cada vértice de la ronda impar se interpreta como un voto. 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 necesitan más rondas para esperar que los anclajes sean ordenados. En situaciones comunes, los vértices en la ronda impar requieren tres rondas, mientras que los vértices no ancla en la ronda par requieren cuatro rondas.
Problema 2: latencia de casos de fallo, el análisis de latencia anterior se aplica a situaciones sin fallos, por otro lado, si un líder de ronda no logra transmitir lo suficientemente rápido el ancla, no se puede ordenar el ancla ( y por lo tanto se salta ), por lo que todos los vértices no ordenados en las primeras rondas deben esperar a que se ordene el siguiente ancla. Esto reducirá significativamente el rendimiento de la red de replicación geográfica, especialmente porque se utiliza un tiempo de espera de Bullshark 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 la canalización, 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íderes de costo cero 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 canalización y la reputación del líder se consideran problemas difíciles, por las siguientes razones:
Los intentos anteriores de modificar la lógica central de Bullshark en la línea de producción parecen ser, en esencia, imposibles.
La reputación del líder se introduce en DiemBFT y se formaliza en Carousel, y se basa en el rendimiento pasado de los validadores para seleccionar dinámicamente a los futuros líderes, 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 conducir a un orden completamente diferente, lo que plantea el núcleo del problema, es decir, la selección dinámica y determinista del ancla del ciclo es necesaria 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, notamos que la implementación de Bullshark, incluida la que actualmente está en el entorno de producción, no admite estas características.
Protocolo
A pesar de los desafíos mencionados, como dice el refrán, la solución se encuentra oculta detrás de lo simple.
En Shoal, dependemos de la capacidad de ejecutar cálculos locales en DAG y de la capacidad de guardar y reinterpretar la información de rondas anteriores. Con la perspicacia fundamental de que todos los validadores están de acuerdo con el primer anclaje ordenado, Shoal combina secuencialmente múltiples instancias de Bullshark para procesarlas en pipeline, de modo que ) el primer anclaje ordenado es el punto de conmutación de las instancias, así como ( la historia causal del anclaje se utiliza para calcular la reputación de los líderes.
![Explicación detallada del marco Shoal: ¿cómo reducir la latencia de Bullshark en Aptos?])https://img-cdn.gateio.im/webp-social/moments-0b0928cb6240e994c1514c75e080a4b2.webp(
Línea de flujo
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.
Inicialmente, Shoal lanzó la primera instancia de Bullshark en la primera ronda del DAG y la ejecutó hasta determinar 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 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. Los puntos de anclaje de la primera ronda se ordenan 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 se ordena por esa instancia, luego, otra nueva instancia ordena el punto de anclaje en la tercera ronda, y luego el proceso continúa.
![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(
Reputación del líder
Al omitir puntos de anclaje durante la clasificación de Bullshark, la latencia aumentará. En este caso, la técnica de tuberías 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 sea menos probable que se elija al líder correspondiente para manejar los puntos de anclaje perdidos en el futuro, asignando un puntaje a cada nodo de validación según la historia 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 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 filosofía 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 lleguen a un consenso sobre el nuevo mapeo, deben alcanzar un consenso sobre los puntajes, logrando así un acuerdo sobre la historia utilizada para derivar los puntajes.
En Shoal, la cadena de suministro y la reputación de liderazgo pueden combinarse de forma natural, ya que ambas utilizan la misma tecnología central, que es reinterpretar el DAG después de llegar a 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 utilizar 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.
![Explicación detallada del marco Shoal: ¿Cómo reducir la latencia de Bullshark en Aptos?])https://img-cdn.gateio.im/webp-social/moments-9f789cb669f6fcc244ea7ff7648e48b4.webp(
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 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 del tiempo de espera del líder con fallos. 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 pasar por alto a buenos líderes. Por ejemplo, observamos que, en condiciones de alta carga, los líderes en Jolteon/Hotstuff estaban abrumados y el tiempo de espera había expirado antes de que pudieran impulsar el progreso.
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.
7 me gusta
Recompensa
7
5
Compartir
Comentar
0/400
SchrodingersFOMO
· 08-05 13:55
latencia bajó tanto alcista alcista
Ver originalesResponder0
SchroedingerMiner
· 08-05 12:20
Esta velocidad sube más rápido que la temperatura de mi Rig de Minera.
Ver originalesResponder0
MEVSandwich
· 08-03 18:14
latencia ha bajado tanto, siento que va a To the moon
Ver originalesResponder0
MetaMisfit
· 08-03 17:54
Esperando a que Aptos revolucione... ¡con expectativas!
El marco Shoal mejora significativamente el rendimiento de Bullshark en Aptos, con una latencia soltada del 40% al 80%.
Marco Shoal: Reducción significativa de la latencia de Bullshark en Aptos
Resumen
Aptos labs resolvió dos importantes problemas abiertos en DAG BFT, reduciendo significativamente la latencia y eliminando por primera vez la necesidad de tiempos de espera en protocolos prácticos 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 a través de la canalización y la reputación de los líderes. La canalización reduce la latencia de ordenamiento de DAG al introducir un ancla en cada ronda, y la reputación de los líderes mejora aún más el problema de latencia al garantizar que el ancla esté asociada con los nodos de validación más rápidos. Además, la reputación de los líderes permite que Shoal utilice construcciones DAG asíncronas para eliminar los tiempos de espera en todos los escenarios. Esto permite que Shoal proporcione atributos de respuesta universal, que incluyen la respuesta optimista que normalmente se requiere.
Esta tecnología es muy simple, implica ejecutar múltiples instancias del protocolo subyacente en secuencia. Por lo tanto, cuando se instancia con Bullshark, obtenemos un grupo de "tiburones" que están participando en una carrera de relevos.
Motivación
Al buscar un alto rendimiento en las redes blockchain, las personas han estado enfocándose en reducir la complejidad de la comunicación. Sin embargo, este enfoque no ha llevado a un aumento significativo en el rendimiento. Por ejemplo, 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 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, 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.
Antes presentamos Quorum Store, nuestra implementación de Narwhal que separa la propagación de datos de la consensus, 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 al estilo PBFT, reduciendo 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 de la consensus, a medida que aumenta el rendimiento, el líder de Hotstuff/Jolteon sigue estando limitado.
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 el alto rendimiento de Bullshark trae un costo de latencia del 50%.
Este artículo presenta cómo Shoal logra reducir significativamente la latencia de Bullshark.
Contexto de DAG-BFT
Cada vértice en el DAG de Narwhal está asociado con una 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 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 de DAG no es ambigua: 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 llegar a un consenso sobre el orden total de todos los vértices en el DAG sin costos 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 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: cada pocas rondas hay un líder predeterminado, el vértice del líder se llama punto de anclaje;
Puntos de anclaje de pedido: los validadores deciden de manera independiente pero determinista qué puntos de anclaje pedir y cuáles omitir;
Historial causal de pedidos: los validadores procesan uno por uno la lista de anclajes ordenados y ordenan todos los vértices desordenados anteriores en el historial causal de cada anclaje.
La clave para cumplir con 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 acuerdan el primer punto de anclaje ordenado.
Bullshark latencia
La latencia de Bullshark depende del número de rondas entre los anclajes 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, está lejos de ser la óptima.
Pregunta 1: Latencia promedio de bloques. En Bullshark, cada ronda par tiene un ancla, y cada vértice de la ronda impar se interpreta como un voto. 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 necesitan más rondas para esperar que los anclajes sean ordenados. En situaciones comunes, los vértices en la ronda impar requieren tres rondas, mientras que los vértices no ancla en la ronda par requieren cuatro rondas.
Problema 2: latencia de casos de fallo, el análisis de latencia anterior se aplica a situaciones sin fallos, por otro lado, si un líder de ronda no logra transmitir lo suficientemente rápido el ancla, no se puede ordenar el ancla ( y por lo tanto se salta ), por lo que todos los vértices no ordenados en las primeras rondas deben esperar a que se ordene el siguiente ancla. Esto reducirá significativamente el rendimiento de la red de replicación geográfica, especialmente porque se utiliza un tiempo de espera de Bullshark 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 la canalización, 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íderes de costo cero 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 canalización y la reputación del líder se consideran problemas difíciles, por las siguientes razones:
Los intentos anteriores de modificar la lógica central de Bullshark en la línea de producción parecen ser, en esencia, imposibles.
La reputación del líder se introduce en DiemBFT y se formaliza en Carousel, y se basa en el rendimiento pasado de los validadores para seleccionar dinámicamente a los futuros líderes, 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 conducir a un orden completamente diferente, lo que plantea el núcleo del problema, es decir, la selección dinámica y determinista del ancla del ciclo es necesaria 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, notamos que la implementación de Bullshark, incluida la que actualmente está en el entorno de producción, no admite estas características.
Protocolo
A pesar de los desafíos mencionados, como dice el refrán, la solución se encuentra oculta detrás de lo simple.
En Shoal, dependemos de la capacidad de ejecutar cálculos locales en DAG y de la capacidad de guardar y reinterpretar la información de rondas anteriores. Con la perspicacia fundamental de que todos los validadores están de acuerdo con el primer anclaje ordenado, Shoal combina secuencialmente múltiples instancias de Bullshark para procesarlas en pipeline, de modo que ) el primer anclaje ordenado es el punto de conmutación de las instancias, así como ( la historia causal del anclaje se utiliza para calcular la reputación de los líderes.
![Explicación detallada del marco Shoal: ¿cómo reducir la latencia de Bullshark en Aptos?])https://img-cdn.gateio.im/webp-social/moments-0b0928cb6240e994c1514c75e080a4b2.webp(
Línea de flujo
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.
Inicialmente, Shoal lanzó la primera instancia de Bullshark en la primera ronda del DAG y la ejecutó hasta determinar 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 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. Los puntos de anclaje de la primera ronda se ordenan 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 se ordena por esa instancia, luego, otra nueva instancia ordena el punto de anclaje en la tercera ronda, y luego el proceso continúa.
![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(
Reputación del líder
Al omitir puntos de anclaje durante la clasificación de Bullshark, la latencia aumentará. En este caso, la técnica de tuberías 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 sea menos probable que se elija al líder correspondiente para manejar los puntos de anclaje perdidos en el futuro, asignando un puntaje a cada nodo de validación según la historia 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 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 filosofía 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 lleguen a un consenso sobre el nuevo mapeo, deben alcanzar un consenso sobre los puntajes, logrando así un acuerdo sobre la historia utilizada para derivar los puntajes.
En Shoal, la cadena de suministro y la reputación de liderazgo pueden combinarse de forma natural, ya que ambas utilizan la misma tecnología central, que es reinterpretar el DAG después de llegar a 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 utilizar 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.
![Explicación detallada del marco Shoal: ¿Cómo reducir la latencia de Bullshark en Aptos?])https://img-cdn.gateio.im/webp-social/moments-9f789cb669f6fcc244ea7ff7648e48b4.webp(
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 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 del tiempo de espera del líder con fallos. 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 pasar por alto a buenos líderes. Por ejemplo, observamos que, en condiciones de alta carga, los líderes en Jolteon/Hotstuff estaban abrumados y el tiempo de espera había expirado antes de que pudieran impulsar el progreso.
desafortunado