Marco Shoal: ¿Cómo soltar 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 tiempo de espera en protocolos de consenso deterministas. En general, mejoró la latencia de Bullshark en un 40% en situaciones sin fallos y en un 80% en situaciones con fallos.
Shoal es un marco que mejora el protocolo de consenso basado en Narwhal ( a través de la canalización y la reputación del líder, como DAG-Rider, Tusk, Bullshark ). La canalización 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 a Shoal aprovechar la construcción de DAG asíncrona 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, implica ejecutar múltiples instancias del protocolo subyacente en orden secuencial. Por lo tanto, cuando se instancia con Bullshark, obtenemos un grupo de "tiburones" que están en una carrera de relevos.
Motivación
En la búsqueda de un alto rendimiento en las redes de blockchain, la gente ha estado centrada 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 del objetivo de 100k+ TPS.
Los recientes avances provienen 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, 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 reporta 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, así como 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 los cambios de vista al 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, a medida que aumenta el rendimiento, el líder de Hotstuff/Jolteon sigue estando limitado.
Por lo tanto, decidimos desplegar Bullshark sobre Narwhal DAG, que es un protocolo de consenso de 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 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 de las propiedades clave de un DAG es que no es ambiguo: si dos nodos de validación tienen el mismo vértice v en sus vistas locales del DAG, entonces tienen la misma historia causal de v.
Clasificación general
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 de grupos en la estructura DAG es diferente, todos los protocolos de consenso basados en Narwhal existentes tienen la siguiente estructura:
Punto de anclaje reservado: cada pocas rondas (, por ejemplo, en Bullshark habrá un líder predefinido cada dos rondas ), y el vértice 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;
ordenando la historia causal: los validadores procesan uno tras otro su lista de puntos de anclaje ordenados, y para cada punto de anclaje, ordenan todos los vértices desordenados anteriores en su historia causal a través de 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, para que todas las listas compartan el mismo prefijo. En Shoal, hacemos las siguientes observaciones sobre todos los protocolos anteriores:
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 de sincronización más práctica de Bullshark tiene una mejor latencia que la versión asíncrona, aún está lejos de ser la óptima.
Pregunta 1: latencia promedio de bloques. En Bullshark, cada ronda par tiene un ancla, y los vértices de cada ronda impar se interpretan como votos. En casos comunes, se necesitan dos rondas de DAG para ordenar anclas; sin embargo, los vértices en la historia causal del ancla necesitan más rondas para esperar que el ancla sea ordenado. En casos comunes, los vértices en la ronda impar necesitan tres rondas, mientras que los vértices no ancla en la ronda par necesitan cuatro rondas.
Problema 2: latencia de casos de fallos, el análisis de latencia anterior se aplica a situaciones sin fallos, por otro lado, si el líder de una ronda no logra difundir los puntos de anclaje lo suficientemente rápido, no se puede ordenar los puntos de anclaje ( 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 punto de anclaje. Esto disminuirá significativamente el rendimiento de la red de replicación geográfica, especialmente porque se usa un tiempo de espera 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 pipelining, 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íder 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 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, y es la selección dinámica de futuros líderes basada en el rendimiento pasado de los validadores en el ancla de 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, que elegir anclas de forma dinámica y determinista es necesario para resolver el consenso, y los validadores necesitan llegar a un acuerdo sobre la historia ordenada para seleccionar 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.
![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(
Protocolo
A pesar de los desafíos mencionados, como dice el refrán, la solución se encuentra en la simplicidad.
En Shoal, dependemos de la capacidad de realizar cálculos locales sobre el DAG y hemos logrado la capacidad de guardar y reinterpretar la información de rondas anteriores. Con la idea central de que todos los validadores aceptan el primer ancla ordenada, Shoal combina secuencialmente múltiples instancias de Bullshark para procesarlas en cadena, lo que hace que ) el primer ancla ordenada sea el punto de cambio de las instancias, así como ( la historia causal del ancla se utiliza para calcular la reputación de los líderes.
Línea de flujo
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 está predefinida por el mapeo F. Cada instancia solicita un ancla, lo que provoca el cambio a la siguiente instancia.
Inicialmente, Shoal lanzó la primera instancia de Bullshark en la primera ronda de DAG y la ejecutó hasta determinar 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 confiable reinterpretar 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 pedir un ancla en cada ronda. El punto de anclaje de la primera ronda se ordena según la primera instancia. Luego, Shoal inicia una nueva instancia en la segunda ronda, que tiene su propio punto de anclaje, el cual es ordenado por esa instancia, y luego, otra nueva instancia pide el punto de anclaje en la tercera ronda, y 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
Durante el periodo de ordenación de Bullshark, al saltar un punto de anclaje, la latencia aumentará. En este caso, la técnica de canalización 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 menos probable que se elija a un 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 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, se asignará una puntuación baja a los nodos de validación, ya que pueden estar en caída, lentos o actuar mal.
Su concepto es recalcular de manera determinista el mapeo predefinido F desde la ronda hasta el líder cada vez que se actualizan los puntajes, inclinándose hacia los líderes con puntajes más altos. Para que los validadores lleguen a un consenso sobre el nuevo mapeo, deben llegar a un consenso sobre los puntajes, logrando así un consenso en la historia utilizada para derivar los puntajes.
En Shoal, las líneas de producción y la reputación del 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 según la historia causal de los puntos de anclaje ordenados en la ronda r. Luego, los nodos de validación utilizan 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 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 necesita 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 por la latencia de tiempo de espera para el líder fallido. Por lo tanto, la configuración del tiempo de espera no puede ser demasiado conservadora, pero si
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.
16 me gusta
Recompensa
16
6
Republicar
Compartir
Comentar
0/400
SlowLearnerWang
· 08-16 21:57
latencia disminuyó un 40%... ¿este bug está demasiado alcista?
Ver originalesResponder0
NFTArchaeologis
· 08-16 21:56
Como si los caracteres de los huesos oraculares estuvieran grabados en la cadena digital, el marco de Shoal se renueva cuando se enturbia.
Ver originalesResponder0
PumpDetector
· 08-16 21:55
hmm alcista de tiburón volviéndose más rápido pero aún leyendo entre líneas... algo se siente raro, no voy a mentir
Ver originalesResponder0
SerumSquirrel
· 08-16 21:53
¿Un aumento del 40% es tan loco?
Ver originalesResponder0
DegenWhisperer
· 08-16 21:51
¿Cuánto dinero hay que gastar para optimizar la latencia?
Ver originalesResponder0
MetaverseLandlord
· 08-16 21:42
Esto ha cambiado completamente las reglas del juego.
Optimización del marco Shoal para el consenso de Aptos, Soltar significativamente la latencia de Bullshark.
Marco Shoal: ¿Cómo soltar 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 tiempo de espera en protocolos de consenso deterministas. En general, mejoró la latencia de Bullshark en un 40% en situaciones sin fallos y en un 80% en situaciones con fallos.
Shoal es un marco que mejora el protocolo de consenso basado en Narwhal ( a través de la canalización y la reputación del líder, como DAG-Rider, Tusk, Bullshark ). La canalización 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 a Shoal aprovechar la construcción de DAG asíncrona 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, implica ejecutar múltiples instancias del protocolo subyacente en orden secuencial. Por lo tanto, cuando se instancia con Bullshark, obtenemos un grupo de "tiburones" que están en una carrera de relevos.
Motivación
En la búsqueda de un alto rendimiento en las redes de blockchain, la gente ha estado centrada 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 del objetivo de 100k+ TPS.
Los recientes avances provienen 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, 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 reporta 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, así como 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 los cambios de vista al 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, a medida que aumenta el rendimiento, el líder de Hotstuff/Jolteon sigue estando limitado.
Por lo tanto, decidimos desplegar Bullshark sobre Narwhal DAG, que es un protocolo de consenso de 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 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 de las propiedades clave de un DAG es que no es ambiguo: si dos nodos de validación tienen el mismo vértice v en sus vistas locales del DAG, entonces tienen la misma historia causal de v.
Clasificación general
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 de grupos en la estructura DAG es diferente, todos los protocolos de consenso basados en Narwhal existentes tienen la siguiente estructura:
Punto de anclaje reservado: cada pocas rondas (, por ejemplo, en Bullshark habrá un líder predefinido cada dos rondas ), y el vértice 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;
ordenando la historia causal: los validadores procesan uno tras otro su lista de puntos de anclaje ordenados, y para cada punto de anclaje, ordenan todos los vértices desordenados anteriores en su historia causal a través de 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, para que todas las listas compartan el mismo prefijo. En Shoal, hacemos las siguientes observaciones sobre todos los protocolos anteriores:
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 de sincronización más práctica de Bullshark tiene una mejor latencia que la versión asíncrona, aún está lejos de ser la óptima.
Pregunta 1: latencia promedio de bloques. En Bullshark, cada ronda par tiene un ancla, y los vértices de cada ronda impar se interpretan como votos. En casos comunes, se necesitan dos rondas de DAG para ordenar anclas; sin embargo, los vértices en la historia causal del ancla necesitan más rondas para esperar que el ancla sea ordenado. En casos comunes, los vértices en la ronda impar necesitan tres rondas, mientras que los vértices no ancla en la ronda par necesitan cuatro rondas.
Problema 2: latencia de casos de fallos, el análisis de latencia anterior se aplica a situaciones sin fallos, por otro lado, si el líder de una ronda no logra difundir los puntos de anclaje lo suficientemente rápido, no se puede ordenar los puntos de anclaje ( 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 punto de anclaje. Esto disminuirá significativamente el rendimiento de la red de replicación geográfica, especialmente porque se usa un tiempo de espera 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 pipelining, 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íder 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 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, y es la selección dinámica de futuros líderes basada en el rendimiento pasado de los validadores en el ancla de 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, que elegir anclas de forma dinámica y determinista es necesario para resolver el consenso, y los validadores necesitan llegar a un acuerdo sobre la historia ordenada para seleccionar 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.
![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(
Protocolo
A pesar de los desafíos mencionados, como dice el refrán, la solución se encuentra en la simplicidad.
En Shoal, dependemos de la capacidad de realizar cálculos locales sobre el DAG y hemos logrado la capacidad de guardar y reinterpretar la información de rondas anteriores. Con la idea central de que todos los validadores aceptan el primer ancla ordenada, Shoal combina secuencialmente múltiples instancias de Bullshark para procesarlas en cadena, lo que hace que ) el primer ancla ordenada sea el punto de cambio de las instancias, así como ( la historia causal del ancla se utiliza para calcular la reputación de los líderes.
Línea de flujo
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 está predefinida por el mapeo F. Cada instancia solicita un ancla, lo que provoca el cambio a la siguiente instancia.
Inicialmente, Shoal lanzó la primera instancia de Bullshark en la primera ronda de DAG y la ejecutó hasta determinar 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 confiable reinterpretar 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 pedir un ancla en cada ronda. El punto de anclaje de la primera ronda se ordena según la primera instancia. Luego, Shoal inicia una nueva instancia en la segunda ronda, que tiene su propio punto de anclaje, el cual es ordenado por esa instancia, y luego, otra nueva instancia pide el punto de anclaje en la tercera ronda, y 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
Durante el periodo de ordenación de Bullshark, al saltar un punto de anclaje, la latencia aumentará. En este caso, la técnica de canalización 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 menos probable que se elija a un 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 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, se asignará una puntuación baja a los nodos de validación, ya que pueden estar en caída, lentos o actuar mal.
Su concepto es recalcular de manera determinista el mapeo predefinido F desde la ronda hasta el líder cada vez que se actualizan los puntajes, inclinándose hacia los líderes con puntajes más altos. Para que los validadores lleguen a un consenso sobre el nuevo mapeo, deben llegar a un consenso sobre los puntajes, logrando así un consenso en la historia utilizada para derivar los puntajes.
En Shoal, las líneas de producción y la reputación del 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 según la historia causal de los puntos de anclaje ordenados en la ronda r. Luego, los nodos de validación utilizan 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 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 necesita 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 por la latencia de tiempo de espera para el líder fallido. Por lo tanto, la configuración del tiempo de espera no puede ser demasiado conservadora, pero si