Marco Shoal: Reduce drásticamente la latencia de Bullshark en Aptos
Aptos Labs ha resuelto recientemente dos importantes problemas abiertos en DAG BFT, reduciendo significativamente la latencia y eliminando por primera vez la necesidad de un tiempo de espera en un protocolo de utilidad determinista. En general, en condiciones sin fallos, la latencia de Bullshark se ha mejorado en un 40%, y en condiciones con fallos, se ha mejorado en un 80%.
Shoal es un marco que mejora el protocolo de consenso basado en Narwhal ( a través de un mecanismo de canalización y reputación de líderes, 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 de los líderes 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 de los líderes 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 propiedades de respuesta universal, que incluyen respuestas optimistas que normalmente se requieren.
Esta tecnología es muy simple, ya que implica ejecutar múltiples instancias del protocolo subyacente una tras otra en orden. Por lo tanto, cuando se instancia Bullshark, obtendremos un grupo de "tiburones" que están en una carrera de relevos.
Fondo
En la búsqueda de un alto rendimiento en las redes de blockchain, la gente ha 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, el Hotstuff implementado en las primeras versiones de Diem solo alcanzó 3500 TPS, muy por debajo del objetivo de más de 100,000 TPS.
El reciente avance se debe a la comprensión de que la difusión de datos es el principal cuello de botella basado en el protocolo de líderes, y puede beneficiarse de la paralelización. El sistema Narwhal separa la difusión de datos de la lógica de consenso central, proponiendo una arquitectura en la que todos los validadores difunden datos simultáneamente, 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.
Anteriormente presentamos Quorum Store, que es nuestra implementación de Narwhal que separa la propagación de datos y el 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, 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 y el consenso, a medida que aumenta el rendimiento, el líder de Hotstuff/Jolteon sigue estando limitado.
Por lo tanto, hemos decidido 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 trae un costo de latencia del 50%.
Este artículo presenta cómo Shoal reduce significativamente la latencia de Bullshark.
Fondo de DAG-BFT
Cada vértice en el DAG de Narwhal está relacionado 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 referirse al menos a 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 es que 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 alcanzar un consenso sobre el orden total de todos los vértices en el DAG sin costos adicionales de comunicación. Para ello, los validadores en DAG-Rider, Tusk y Bullshark interpretan la estructura del DAG como un protocolo de consenso, donde los vértices representan propuestas y las aristas representan votos.
Aunque la lógica de intersección de grupos en la estructura DAG es diferente, todos los protocolos de consenso basados en Narwhal existentes tienen la siguiente estructura:
Punto de anclaje programado: cada pocas rondas (, como en dos rondas de Bullshark ), hay un líder predeterminado, y el vértice del líder se llama punto de anclaje.
Puntos de anclaje de ordenación: los validadores deciden de manera independiente pero determinista qué puntos de anclaje ordenar y cuáles omitir.
Historia de causalidad ordenada: los validadores procesan uno a uno la lista de puntos de anclaje ordenados, y para cada punto de anclaje, ordenan todos los vértices anteriores desordenados en su historia causal a través de ciertas reglas deterministas.
La clave para satisfacer la seguridad es garantizar que en el paso (2), todas las listas de anclajes ordenados creadas por nodos de verificación honestos compartan el mismo prefijo. En Shoal, hacemos las siguientes observaciones sobre todos estos protocolos:
Todos los validadores están de acuerdo con el primer ancla ordenada.
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 mejor latencia 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 punto de anclaje, mientras que los vértices de las rondas impares se interpretan como votos. En la mayoría de los casos, 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 necesitan más rondas para esperar que se ordenen los puntos de anclaje. En situaciones comunes, los vértices en las rondas impares requieren tres rondas, mientras que los vértices no anclados en las rondas pares requieren cuatro rondas.
Problema 2: latencia 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 transmitir el punto de anclaje lo suficientemente rápido, no se puede ordenar dicho punto de anclaje (, por lo que se salta ). Por lo tanto, todos los vértices no ordenados de las rondas anteriores deben esperar a que el siguiente punto de anclaje sea ordenado. Esto puede reducir significativamente el rendimiento de la red de replicación geográfica, especialmente porque Bullshark utiliza tiempos de espera para esperar al líder.
Marco Shoal
Shoal resolvió estos dos problemas de latencia, mejorando Bullshark( o cualquier otro protocolo BFT basado en Narwhal) a través de un pipeline, permitiendo que en cada ronda haya un punto de anclaje, 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 sin 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 canalización y la reputación del líder se consideran problemas difíciles, por las siguientes razones:
Los intentos anteriores de la línea de producción 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 futuros líderes en función del desempeño pasado de los validadores, la idea del ancla en Bullshark (. Aunque las discrepancias en la identidad del líder no violan la seguridad de estos protocolos, en Bullshark, podría conducir a un orden completamente diferente, lo que plantea el núcleo del problema, a saber, que la selección dinámica y determinista del ancla del ciclo es necesaria para resolver el consenso, y los validadores deben 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.
![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(
Protocolo
A pesar de los desafíos mencionados, la solución resultó estar oculta en la simplicidad.
En Shoal, confiamos en la capacidad de realizar cálculos locales en el DAG y hemos logrado la capacidad de guardar 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 pipeline, haciendo que ) el primer ancla ordenada sea 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.
Línea de producción
V que asigna rondas a líderes. Shoal ejecuta instancias de Bullshark una tras otra, de modo que para cada instancia, el ancla es determinada previamente por el mapeo F. Cada instancia ordena un ancla, lo que desencadena el cambio a la siguiente instancia.
Al principio, Shoal inició la primera instancia de Bullshark en la primera ronda del DAG y la ejecutó hasta determinar el primer punto de anclaje ordenado, como en la ronda r. Todos los validadores acordaron este punto de anclaje. Por lo tanto, todos los validadores pueden acordar con certeza reinterpretar el DAG a partir de la ronda r+1. Shoal simplemente inició 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. 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 ordena 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-9f789cb669f6fcc244ea7ff7648e48b4.webp(
Reputación del líder
Cuando se omiten los puntos de anclaje durante el ordenamiento de Bullshark, la latencia aumenta. En este caso, la técnica de tuberías es impotente, 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 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 un mecanismo de reputación. Los validadores que responden y participan en el protocolo recibirán una puntuación alta; de lo contrario, los nodos de validación recibirán una puntuación baja, ya que pueden fallar, ser lentos o actuar maliciosamente.
Su concepto es recalcular de manera determinista el mapeo predefinido F desde la ronda hasta el líder cada vez que se actualiza la puntuación, favoreciendo a los líderes con puntuaciones más altas. Para que los validadores lleguen a un consenso sobre el nuevo mapeo, deben llegar a un consenso sobre las puntuaciones, logrando así un consenso sobre la historia utilizada para derivar las puntuaciones.
En Shoal, la cadena de suministro y la reputación del liderazgo pueden combinarse naturalmente, ya que ambas utilizan la misma tecnología central, que es 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, basándose 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 reducir la latencia de Bullshark en Aptos?])https://img-cdn.gateio.im/webp-social/moments-1baf540693f376d93cb18ef3193593cc.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 transferirse al siguiente líder, el protocolo pagará la penalización completa de latencia por el líder fallido.
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.
14 me gusta
Recompensa
14
6
Compartir
Comentar
0/400
CryptoSurvivor
· 08-06 08:15
alcista 这波升级让aptos提速了
Ver originalesResponder0
SelfSovereignSteve
· 08-06 08:14
Esta actualización está alcista, ¡un aumento del 40% es demasiado fuerte!
Ver originalesResponder0
GasFeeCrier
· 08-06 08:13
Steam桑哒, ahora el problema de latencia está solucionado.
Ver originalesResponder0
MissedTheBoat
· 08-06 08:04
Comercio de criptomonedas tontos finalmente han ganado.
Ver originalesResponder0
Tians
· 08-06 07:50
firme HODL💎
Ver originalesResponder0
SneakyFlashloan
· 08-06 07:48
increíble latencia directamente reducida a más de la mitad
El marco Shoal reduce significativamente la latencia de Bullshark en la cadena de bloques Aptos.
Marco Shoal: Reduce drásticamente la latencia de Bullshark en Aptos
Aptos Labs ha resuelto recientemente dos importantes problemas abiertos en DAG BFT, reduciendo significativamente la latencia y eliminando por primera vez la necesidad de un tiempo de espera en un protocolo de utilidad determinista. En general, en condiciones sin fallos, la latencia de Bullshark se ha mejorado en un 40%, y en condiciones con fallos, se ha mejorado en un 80%.
Shoal es un marco que mejora el protocolo de consenso basado en Narwhal ( a través de un mecanismo de canalización y reputación de líderes, 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 de los líderes 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 de los líderes 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 propiedades de respuesta universal, que incluyen respuestas optimistas que normalmente se requieren.
Esta tecnología es muy simple, ya que implica ejecutar múltiples instancias del protocolo subyacente una tras otra en orden. Por lo tanto, cuando se instancia Bullshark, obtendremos un grupo de "tiburones" que están en una carrera de relevos.
Fondo
En la búsqueda de un alto rendimiento en las redes de blockchain, la gente ha 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, el Hotstuff implementado en las primeras versiones de Diem solo alcanzó 3500 TPS, muy por debajo del objetivo de más de 100,000 TPS.
El reciente avance se debe a la comprensión de que la difusión de datos es el principal cuello de botella basado en el protocolo de líderes, y puede beneficiarse de la paralelización. El sistema Narwhal separa la difusión de datos de la lógica de consenso central, proponiendo una arquitectura en la que todos los validadores difunden datos simultáneamente, 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.
Anteriormente presentamos Quorum Store, que es nuestra implementación de Narwhal que separa la propagación de datos y el 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, 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 y el consenso, a medida que aumenta el rendimiento, el líder de Hotstuff/Jolteon sigue estando limitado.
Por lo tanto, hemos decidido 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 trae un costo de latencia del 50%.
Este artículo presenta cómo Shoal reduce significativamente la latencia de Bullshark.
Fondo de DAG-BFT
Cada vértice en el DAG de Narwhal está relacionado 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 referirse al menos a 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 es que 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 alcanzar un consenso sobre el orden total de todos los vértices en el DAG sin costos adicionales de comunicación. Para ello, los validadores en DAG-Rider, Tusk y Bullshark interpretan la estructura del DAG como un protocolo de consenso, donde los vértices representan propuestas y las aristas representan votos.
Aunque la lógica de intersección de grupos en la estructura DAG es diferente, todos los protocolos de consenso basados en Narwhal existentes tienen la siguiente estructura:
Punto de anclaje programado: cada pocas rondas (, como en dos rondas de Bullshark ), hay un líder predeterminado, y el vértice del líder se llama punto de anclaje.
Puntos de anclaje de ordenación: los validadores deciden de manera independiente pero determinista qué puntos de anclaje ordenar y cuáles omitir.
Historia de causalidad ordenada: los validadores procesan uno a uno la lista de puntos de anclaje ordenados, y para cada punto de anclaje, ordenan todos los vértices anteriores desordenados en su historia causal a través de ciertas reglas deterministas.
La clave para satisfacer la seguridad es garantizar que en el paso (2), todas las listas de anclajes ordenados creadas por nodos de verificación honestos compartan el mismo prefijo. En Shoal, hacemos las siguientes observaciones sobre todos estos protocolos:
Todos los validadores están de acuerdo con el primer ancla ordenada.
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 mejor latencia 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 punto de anclaje, mientras que los vértices de las rondas impares se interpretan como votos. En la mayoría de los casos, 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 necesitan más rondas para esperar que se ordenen los puntos de anclaje. En situaciones comunes, los vértices en las rondas impares requieren tres rondas, mientras que los vértices no anclados en las rondas pares requieren cuatro rondas.
Problema 2: latencia 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 transmitir el punto de anclaje lo suficientemente rápido, no se puede ordenar dicho punto de anclaje (, por lo que se salta ). Por lo tanto, todos los vértices no ordenados de las rondas anteriores deben esperar a que el siguiente punto de anclaje sea ordenado. Esto puede reducir significativamente el rendimiento de la red de replicación geográfica, especialmente porque Bullshark utiliza tiempos de espera para esperar al líder.
Marco Shoal
Shoal resolvió estos dos problemas de latencia, mejorando Bullshark( o cualquier otro protocolo BFT basado en Narwhal) a través de un pipeline, permitiendo que en cada ronda haya un punto de anclaje, 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 sin 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 canalización y la reputación del líder se consideran problemas difíciles, por las siguientes razones:
Los intentos anteriores de la línea de producción 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 futuros líderes en función del desempeño pasado de los validadores, la idea del ancla en Bullshark (. Aunque las discrepancias en la identidad del líder no violan la seguridad de estos protocolos, en Bullshark, podría conducir a un orden completamente diferente, lo que plantea el núcleo del problema, a saber, que la selección dinámica y determinista del ancla del ciclo es necesaria para resolver el consenso, y los validadores deben 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.
![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(
Protocolo
A pesar de los desafíos mencionados, la solución resultó estar oculta en la simplicidad.
En Shoal, confiamos en la capacidad de realizar cálculos locales en el DAG y hemos logrado la capacidad de guardar 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 pipeline, haciendo que ) el primer ancla ordenada sea 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.
Línea de producción
V que asigna rondas a líderes. Shoal ejecuta instancias de Bullshark una tras otra, de modo que para cada instancia, el ancla es determinada previamente por el mapeo F. Cada instancia ordena un ancla, lo que desencadena el cambio a la siguiente instancia.
Al principio, Shoal inició la primera instancia de Bullshark en la primera ronda del DAG y la ejecutó hasta determinar el primer punto de anclaje ordenado, como en la ronda r. Todos los validadores acordaron este punto de anclaje. Por lo tanto, todos los validadores pueden acordar con certeza reinterpretar el DAG a partir de la ronda r+1. Shoal simplemente inició 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. 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 ordena 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-9f789cb669f6fcc244ea7ff7648e48b4.webp(
Reputación del líder
Cuando se omiten los puntos de anclaje durante el ordenamiento de Bullshark, la latencia aumenta. En este caso, la técnica de tuberías es impotente, 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 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 un mecanismo de reputación. Los validadores que responden y participan en el protocolo recibirán una puntuación alta; de lo contrario, los nodos de validación recibirán una puntuación baja, ya que pueden fallar, ser lentos o actuar maliciosamente.
Su concepto es recalcular de manera determinista el mapeo predefinido F desde la ronda hasta el líder cada vez que se actualiza la puntuación, favoreciendo a los líderes con puntuaciones más altas. Para que los validadores lleguen a un consenso sobre el nuevo mapeo, deben llegar a un consenso sobre las puntuaciones, logrando así un consenso sobre la historia utilizada para derivar las puntuaciones.
En Shoal, la cadena de suministro y la reputación del liderazgo pueden combinarse naturalmente, ya que ambas utilizan la misma tecnología central, que es 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, basándose 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 reducir la latencia de Bullshark en Aptos?])https://img-cdn.gateio.im/webp-social/moments-1baf540693f376d93cb18ef3193593cc.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 transferirse al siguiente líder, el protocolo pagará la penalización completa de latencia por el líder fallido.