Marco Shoal: Soltar la latencia de Bullshark en Aptos
Aptos Labs recientemente resolvió dos importantes problemas abiertos en DAG BFT, Soltando significativamente la latencia y eliminando por primera vez la necesidad de tiempo de espera en el protocolo práctico determinista. En general, en condiciones sin fallos, la latencia de Bullshark mejoró en un 40%, y en caso de fallos mejoró en un 80%.
Shoal es un marco que mejora cualquier protocolo de consenso basado en Narwhal ( como DAG-Rider, Tusk, Bullshark ) a través de una línea de producción y la reputación del líder. La línea de producción reduce la latencia del ordenamiento del DAG al introducir un punto de anclaje en cada ronda, y la reputación del líder mejora aún más la 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 aproveche la construcción de DAG asíncrona para eliminar los tiempos de espera en todos los escenarios. Esto permite que Shoal ofrezca la propiedad que llamamos respuesta universal, que contiene la respuesta optimista que normalmente se requiere.
Nuestra tecnología es muy simple, implica ejecutar múltiples instancias del protocolo subyacente una tras otra. 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 perseguir un alto rendimiento en las redes de blockchain, las personas han estado centradas en Soltar 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 logró 3500 TPS, muy por debajo de nuestro objetivo de lograr más de 100k TPS.
Sin embargo, el reciente avance proviene de 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 central y propone una arquitectura en la que todos los validadores propagan datos simultáneamente, mientras que el componente de consenso solo ordena una cantidad reducida de metadatos. El documento de Narwhal reportó un rendimiento de 160,000 TPS.
En artículos anteriores, presentamos Quorum Store. Nuestra implementación de Narwhal separa la propagación de datos del consenso, y cómo lo usamos 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 Soltar la latencia de Hotstuff en un 33%. Sin embargo, es evidente que los protocolos de consenso basados en líderes no pueden aprovechar plenamente el potencial de rendimiento de Narwhal. A pesar de separar la propagación de datos del consenso, con el aumento del rendimiento, el líder de Hotstuff/Jolteon aún se ve limitado.
Por lo tanto, decidimos desplegar Bullshark sobre Narwhal DAG, un protocolo de consenso sin costo de comunicación. Desafortunadamente, en comparación con Jolteon, la estructura DAG que soporta el alto rendimiento de Bullshark conlleva un costo de latencia del 50%.
En este artículo, presentamos cómo Shoal logra Soltar significativamente la latencia de Bullshark.
Fondo DAG-BFT
Comencemos por entender el contexto relevante de este artículo.
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 la misma historia causal de v.
Orden total
Se puede alcanzar 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 intersección grupal 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 (, por ejemplo, en dos rondas de Bullshark ) habrá un líder previamente determinado, el pico del líder se llama punto de anclaje;
Puntos de anclaje ordenados: los validadores deciden de manera independiente pero determinista qué puntos de anclaje ordenar y cuáles omitir;
Ordenar la historia causal: 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 causal mediante algunas reglas deterministas.
La clave para satisfacer la seguridad es asegurar que en los pasos anteriores (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 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 la óptima.
Pregunta 1: latencia media 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 casos 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 casos 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 falla, el análisis de latencia anterior se aplica a situaciones sin fallas, por otro lado, si el líder de una ronda no logra transmitir el ancla lo suficientemente rápido, no se puede ordenar el ancla ( y, por lo tanto, se omite ), 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 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 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 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 tubería y la reputación del líder se consideran problemas difíciles, 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 de los líderes se introduce en DiemBFT y se formaliza en Carousel, seleccionando dinámicamente a los 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, pueden llevar a un orden completamente diferente, lo que plantea el núcleo del problema, es decir, la necesidad de seleccionar los anclajes de manera dinámica y determinista para resolver el consenso, y los validadores deben llegar a un acuerdo sobre el historial ordenado para elegir los futuros anclajes.
Como evidencia de la dificultad de la pregunta, 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, como dice el refrán, la solución se encuentra oculta detrás de la simplicidad.
En Shoal, confiamos en la capacidad de realizar cálculos locales sobre el DAG y logramos la capacidad de almacenar y reinterpretar la información de rondas anteriores. Con la visión central de que todos los validadores acuerdan el primer ancla ordenada, Shoal combina secuencialmente múltiples instancias de Bullshark para procesarlas en una tubería, haciendo que ) el primer ancla ordenada sea el punto de cambio de las instancias, así como ( la historia causal de los anclajes se utilice para calcular la reputación del líder.
![Explicación detallada de 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 rondas a líderes. Shoal ejecuta instancias de Bullshark una tras otra, de modo que para cada instancia, el ancla está predefinida 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 de 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 concluyente 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 por la primera instancia. Luego, Shoal comienza una nueva instancia en la segunda ronda, que tiene su propio punto de anclaje, el cual es ordenado por esa instancia, y luego, otra nueva instancia ordena el punto de anclaje en la tercera ronda, y así continúa el proceso.
![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(
Reputación de los líderes
Durante la clasificación de Bullshark, al omitir el ancla, la latencia aumentará. En este caso, la técnica de tuberías es incapaz, ya que no se puede iniciar una nueva instancia antes de que se ordene el ancla de la instancia anterior. Shoal asegura que sea menos probable seleccionar a los líderes correspondientes para manejar los anclajes 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 un mecanismo de reputación. Los validadores que respondan y participen en el protocolo recibirán una puntuación alta; de lo contrario, a los nodos de validación se les asignará una puntuación baja, ya que pueden fallar, ser lentos o actuar de manera maliciosa.
Su concepto es recalcular de manera determinista el mapeo predefinido F desde la ronda hasta el líder cada vez que se actualicen los puntos, favoreciendo a los líderes con puntajes más altos. Para que los validadores lleguen a un consenso sobre el nuevo mapeo, deben coincidir en los puntos, logrando así un consenso sobre la historia utilizada para derivar los puntajes.
En Shoal, las reputaciones de la línea de producción y 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 llegar a un consenso sobre el primer ancla ordenada.
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, basado 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 utilizando la función de selección de anclajes actualizada F' 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-859e732e16c3eee0e2c93422474debc2.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 se requiere un ajuste dinámico, ya que depende en gran medida del entorno ) red (. Antes de pasar al siguiente líder, el protocolo pagará la penalización completa de latencia por el 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
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
5
Compartir
Comentar
0/400
StableGeniusDegen
· hace19h
¡Tecnología dura! El aumento de precios es inminente
Ver originalesResponder0
EthSandwichHero
· 07-26 07:15
¿La latencia ha soltado? ¡Alcista, alcista, así que To the moon!
Ver originalesResponder0
GasOptimizer
· 07-26 07:14
80% latencia optimizada es mejor que cualquier tarifa de gas.
El marco Shoal mejora significativamente el rendimiento de la red Aptos, Bullshark reduce la latencia en un 80%.
Marco Shoal: Soltar la latencia de Bullshark en Aptos
Aptos Labs recientemente resolvió dos importantes problemas abiertos en DAG BFT, Soltando significativamente la latencia y eliminando por primera vez la necesidad de tiempo de espera en el protocolo práctico determinista. En general, en condiciones sin fallos, la latencia de Bullshark mejoró en un 40%, y en caso de fallos mejoró en un 80%.
Shoal es un marco que mejora cualquier protocolo de consenso basado en Narwhal ( como DAG-Rider, Tusk, Bullshark ) a través de una línea de producción y la reputación del líder. La línea de producción reduce la latencia del ordenamiento del DAG al introducir un punto de anclaje en cada ronda, y la reputación del líder mejora aún más la 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 aproveche la construcción de DAG asíncrona para eliminar los tiempos de espera en todos los escenarios. Esto permite que Shoal ofrezca la propiedad que llamamos respuesta universal, que contiene la respuesta optimista que normalmente se requiere.
Nuestra tecnología es muy simple, implica ejecutar múltiples instancias del protocolo subyacente una tras otra. 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 perseguir un alto rendimiento en las redes de blockchain, las personas han estado centradas en Soltar 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 logró 3500 TPS, muy por debajo de nuestro objetivo de lograr más de 100k TPS.
Sin embargo, el reciente avance proviene de 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 central y propone una arquitectura en la que todos los validadores propagan datos simultáneamente, mientras que el componente de consenso solo ordena una cantidad reducida de metadatos. El documento de Narwhal reportó un rendimiento de 160,000 TPS.
En artículos anteriores, presentamos Quorum Store. Nuestra implementación de Narwhal separa la propagación de datos del consenso, y cómo lo usamos 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 Soltar la latencia de Hotstuff en un 33%. Sin embargo, es evidente que los protocolos de consenso basados en líderes no pueden aprovechar plenamente el potencial de rendimiento de Narwhal. A pesar de separar la propagación de datos del consenso, con el aumento del rendimiento, el líder de Hotstuff/Jolteon aún se ve limitado.
Por lo tanto, decidimos desplegar Bullshark sobre Narwhal DAG, un protocolo de consenso sin costo de comunicación. Desafortunadamente, en comparación con Jolteon, la estructura DAG que soporta el alto rendimiento de Bullshark conlleva un costo de latencia del 50%.
En este artículo, presentamos cómo Shoal logra Soltar significativamente la latencia de Bullshark.
Fondo DAG-BFT
Comencemos por entender el contexto relevante de este artículo.
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 la misma historia causal de v.
Orden total
Se puede alcanzar 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 intersección grupal 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 (, por ejemplo, en dos rondas de Bullshark ) habrá un líder previamente determinado, el pico del líder se llama punto de anclaje;
Puntos de anclaje ordenados: los validadores deciden de manera independiente pero determinista qué puntos de anclaje ordenar y cuáles omitir;
Ordenar la historia causal: 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 causal mediante algunas reglas deterministas.
La clave para satisfacer la seguridad es asegurar que en los pasos anteriores (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 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 la óptima.
Pregunta 1: latencia media 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 casos 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 casos 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 falla, el análisis de latencia anterior se aplica a situaciones sin fallas, por otro lado, si el líder de una ronda no logra transmitir el ancla lo suficientemente rápido, no se puede ordenar el ancla ( y, por lo tanto, se omite ), 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 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 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 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 tubería y la reputación del líder se consideran problemas difíciles, 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 de los líderes se introduce en DiemBFT y se formaliza en Carousel, seleccionando dinámicamente a los 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, pueden llevar a un orden completamente diferente, lo que plantea el núcleo del problema, es decir, la necesidad de seleccionar los anclajes de manera dinámica y determinista para resolver el consenso, y los validadores deben llegar a un acuerdo sobre el historial ordenado para elegir los futuros anclajes.
Como evidencia de la dificultad de la pregunta, 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, como dice el refrán, la solución se encuentra oculta detrás de la simplicidad.
En Shoal, confiamos en la capacidad de realizar cálculos locales sobre el DAG y logramos la capacidad de almacenar y reinterpretar la información de rondas anteriores. Con la visión central de que todos los validadores acuerdan el primer ancla ordenada, Shoal combina secuencialmente múltiples instancias de Bullshark para procesarlas en una tubería, haciendo que ) el primer ancla ordenada sea el punto de cambio de las instancias, así como ( la historia causal de los anclajes se utilice para calcular la reputación del líder.
![Explicación detallada de 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 rondas a líderes. Shoal ejecuta instancias de Bullshark una tras otra, de modo que para cada instancia, el ancla está predefinida 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 de 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 concluyente 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 por la primera instancia. Luego, Shoal comienza una nueva instancia en la segunda ronda, que tiene su propio punto de anclaje, el cual es ordenado por esa instancia, y luego, otra nueva instancia ordena el punto de anclaje en la tercera ronda, y así continúa el proceso.
![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(
Reputación de los líderes
Durante la clasificación de Bullshark, al omitir el ancla, la latencia aumentará. En este caso, la técnica de tuberías es incapaz, ya que no se puede iniciar una nueva instancia antes de que se ordene el ancla de la instancia anterior. Shoal asegura que sea menos probable seleccionar a los líderes correspondientes para manejar los anclajes 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 un mecanismo de reputación. Los validadores que respondan y participen en el protocolo recibirán una puntuación alta; de lo contrario, a los nodos de validación se les asignará una puntuación baja, ya que pueden fallar, ser lentos o actuar de manera maliciosa.
Su concepto es recalcular de manera determinista el mapeo predefinido F desde la ronda hasta el líder cada vez que se actualicen los puntos, favoreciendo a los líderes con puntajes más altos. Para que los validadores lleguen a un consenso sobre el nuevo mapeo, deben coincidir en los puntos, logrando así un consenso sobre la historia utilizada para derivar los puntajes.
En Shoal, las reputaciones de la línea de producción y 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 llegar a un consenso sobre el primer ancla ordenada.
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, basado 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 utilizando la función de selección de anclajes actualizada F' 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-859e732e16c3eee0e2c93422474debc2.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 se requiere un ajuste dinámico, ya que depende en gran medida del entorno ) red (. Antes de pasar al siguiente líder, el protocolo pagará la penalización completa de latencia por el 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