Marco Shoal: ¿Cómo reducir 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 tiempo de espera en los protocolos de consenso deterministas. En general, ha mejorado 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 del procesamiento por tuberías y un mecanismo de reputación de líderes, como DAG-Rider, Tusk, Bullshark ). El procesamiento por tuberías reduce la latencia de ordenación de DAG al introducir un punto de anclaje en cada ronda, y el mecanismo de reputación de 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 líderes 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 características de respuesta universal, que incluyen la respuesta optimista que generalmente se requiere.
La tecnología es muy simple, implica ejecutar múltiples instancias del protocolo subyacente en orden. Por lo tanto, cuando se instancia Bullshark, obtenemos un grupo de "tiburones" que están en una carrera de relevos.
Contexto
En la búsqueda de un alto rendimiento en las redes blockchain, la gente ha estado enfocándose en reducir la complejidad de la comunicación. Sin embargo, este enfoque no ha logrado una mejora significativa en el rendimiento. Por ejemplo, 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 proviene de la comprensión de que la propagación de datos es el principal cuello de botella basado en el protocolo de los líderes, y 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 reportó un rendimiento de 160,000 TPS.
Aptos presentó anteriormente Quorum Store, que es la implementación de Narwhal, separando la propagación de datos del consenso, así como cómo utilizarlo para escalar el protocolo de consenso actual Jolteon. Jolteon es un protocolo basado en líderes que combina la ruta rápida lineal de Tendermint y el cambio de vista al estilo PBFT, lo que puede reducir la latencia de Hotstuff en un 33%. Sin embargo, los protocolos de consenso basados en líderes claramente no pueden aprovechar completamente el potencial de rendimiento de Narwhal. A pesar de separar la propagación de datos del consenso, a medida que aumenta el rendimiento, el líder de Hotstuff/Jolteon sigue estando limitado.
Por lo tanto, Aptos ha decidido implementar Bullshark sobre el DAG de Narwhal, que es un protocolo de consenso con cero sobrecostos 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.
Contexto de DAG-BFT
Cada vértice en el DAG de Narwhal está asociado con una ronda. Para entrar en la ronda r, los validadores deben primero obtener n-f vértices que pertenecen a la ronda r-1. Cada validador puede difundir 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 es la no ambigüedad: si dos nodos de validación tienen el mismo vértice v en su vista local de DAG, entonces tienen una historia causal de v completamente idéntica.
Prefacio
Se puede alcanzar 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 los bordes 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 (, por ejemplo, en Bullshark, cada dos rondas ) habrá un líder previamente determinado, y el pico del líder se denomina punto de anclaje.
Puntos de anclaje ordenados: los validadores deciden de manera independiente pero determinista qué puntos de anclaje ordenar y cuáles omitir.
Historia causal ordenada: los validadores procesan uno tras otro 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 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, se hacen 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 de sincronización de Bullshark es más práctica y tiene una mejor latencia que la versión asincrónica, aún está lejos de ser ó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 los anclajes; sin embargo, los vértices en la historia causal de los anclajes requieren más rondas para esperar que se ordenen. En casos comunes, los vértices en rondas impares necesitan tres rondas, mientras que los vértices no anclados en rondas pares necesitan cuatro rondas.
Problema 2: latencia de casos de falla. El análisis de latencia anterior se aplica a situaciones sin fallas; por otro lado, si un líder de ronda no logra transmitir los puntos de anclaje lo suficientemente rápido, no se pueden clasificar los puntos de anclaje ( y, por lo tanto, se omiten ). Como resultado, todos los vértices no clasificados en las rondas anteriores deben esperar a que se clasifique el siguiente punto de anclaje. Esto reducirá significativamente el rendimiento de la red de replicación geográfica, especialmente porque Bullshark utiliza un tiempo de espera para esperar al líder.
Marco Shoal
Shoal resolvió estos dos problemas de latencia, mejoró Bullshark( o cualquier otro protocolo BFT basado en Narwhal) mediante el procesamiento en línea, permitiendo que haya un punto de anclaje en cada ronda y reduciendo la latencia de todos los vértices no ancla en el DAG a tres rondas. Shoal también introdujo un mecanismo de reputación de líder 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, el procesamiento en pipeline y la reputación del líder se consideran problemas difíciles, por las siguientes razones:
Los intentos anteriores de procesar en línea intentaron modificar la lógica central de Bullshark, pero esto parece ser esencialmente imposible.
La reputación del líder se introduce en DiemBFT y se formaliza en Carousel, seleccionando dinámicamente a los futuros líderes en función del rendimiento pasado de los validadores, 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 ordenamiento completamente diferente, lo que plantea el núcleo del problema, es decir, que la selección dinámica y determinista del ancla de la ronda 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, la implementación de Bullshark, incluida la que actualmente se encuentra en el entorno de producción, no soporta estas características.
Protocolo
A pesar de los desafíos mencionados, la solución se oculta en la simplicidad.
En Shoal, dependemos de 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 están de acuerdo en el primer punto de anclaje ordenado, Shoal combina secuencialmente múltiples instancias de Bullshark para procesarlas en paralelo, de modo que ) el primer punto de anclaje ordenado es el punto de cambio de las instancias, así como ( la historia causal del punto de anclaje se utiliza para calcular la reputación del líder.
![Explicación detallada del marco Shoal: ¿cómo reducir la latencia de Bullshark en Aptos?])https://img-cdn.gateio.im/webp-social/moments-46d37add0d9e81b2f295edf8eddd907f.webp(
Procesamiento en línea
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á predefinido por el mapeo F. Cada instancia clasifica 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 que se determinó el primer anclaje ordenado, como en la ronda r. Todos los validadores estuvieron de acuerdo con este anclaje. Por lo tanto, todos los validadores pueden acordar con certeza 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. El primer punto de anclaje se ordena según la primera instancia. Luego, Shoal inicia una nueva instancia en la segunda ronda, que tiene su propio punto de anclaje, y ese ancla se ordena por esa instancia, luego, otra nueva instancia ordena un 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-0b0928cb6240e994c1514c75e080a4b2.webp(
Reputación del líder
Al omitir puntos de anclaje durante el ordenamiento de Bullshark, la latencia aumentará. En este caso, la técnica de procesamiento en tubería no puede hacer nada, 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 poco probable que se elija al líder correspondiente para manejar los puntos de anclaje perdidos en el futuro, asignando una puntuación a cada nodo de validación según el historial de actividad reciente de cada nodo. Los validadores que responden y participan en el protocolo recibirán una alta puntuación, de lo contrario, los nodos de validación recibirán una baja puntuación, ya que pueden colapsar, ser lentos o actuar de manera maliciosa.
Su filosofía es recalcular de manera determinista el mapeo predefinido F desde la ronda hasta el líder cada vez que se actualiza la puntuación, inclinándose hacia los líderes con puntuaciones más altas. Para que los validadores lleguen a un consenso sobre el nuevo mapeo, deben llegar a un acuerdo sobre las puntuaciones, logrando así un consenso sobre la historia utilizada para derivar las puntuaciones.
En Shoal, el procesamiento en línea y la reputación del líder pueden combinarse de forma natural, ya que ambos utilizan la misma tecnología central, es decir, 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 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-859e732e16c3eee0e2c93422474debc2.webp(
No hay más tiempo de espera
El tiempo de espera juega un papel crucial en todas las implementaciones BFT deterministas basadas en líderes. Sin embargo, la complejidad que introducen incrementa el número de estados internos que necesitan ser gestionados y observados, lo que aumenta la complejidad del proceso de depuración y requiere más técnicas de observabilidad.
Los tiempos de espera también aumentarán significativamente la latencia, ya que es muy importante configurarlos adecuadamente y a menudo requieren ajustes dinámicos, debido a que dependen en gran medida del entorno ) red (. Antes de pasar al siguiente líder, el protocolo paga una penalización completa por el tiempo de espera del líder defectuoso. 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 omitir a buenos líderes. Por ejemplo, hemos observado que, en condiciones de alta carga, los líderes en Jolteon/Hotstuff están abrumados y el tiempo de espera ha expirado antes de que puedan avanzar.
Desafortunadamente, basado en el protocolo del líder ) como
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
ChainSpy
· hace7h
¡Semáforo en verde! APT va a To the moon.
Ver originalesResponder0
AirdropHunter007
· hace18h
¿Latencia reducida en un 40%? ¡To the moon!
Ver originalesResponder0
BTCBeliefStation
· hace18h
increíble Esta optimización me dejó atónito
Ver originalesResponder0
CounterIndicator
· hace18h
alcista ah, la latencia se ha reducido a más de la mitad
Ver originalesResponder0
MoonRocketTeam
· hace18h
Ay, la latencia se ha reducido un 50% de caída, esta ventana de lanzamiento está a punto de despegar.
Optimización del marco Shoal del protocolo de consenso Aptos Bullshark latencia significativamente Soltar
Marco Shoal: ¿Cómo reducir 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 tiempo de espera en los protocolos de consenso deterministas. En general, ha mejorado 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 del procesamiento por tuberías y un mecanismo de reputación de líderes, como DAG-Rider, Tusk, Bullshark ). El procesamiento por tuberías reduce la latencia de ordenación de DAG al introducir un punto de anclaje en cada ronda, y el mecanismo de reputación de 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 líderes 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 características de respuesta universal, que incluyen la respuesta optimista que generalmente se requiere.
La tecnología es muy simple, implica ejecutar múltiples instancias del protocolo subyacente en orden. Por lo tanto, cuando se instancia Bullshark, obtenemos un grupo de "tiburones" que están en una carrera de relevos.
Contexto
En la búsqueda de un alto rendimiento en las redes blockchain, la gente ha estado enfocándose en reducir la complejidad de la comunicación. Sin embargo, este enfoque no ha logrado una mejora significativa en el rendimiento. Por ejemplo, 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 proviene de la comprensión de que la propagación de datos es el principal cuello de botella basado en el protocolo de los líderes, y 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 reportó un rendimiento de 160,000 TPS.
Aptos presentó anteriormente Quorum Store, que es la implementación de Narwhal, separando la propagación de datos del consenso, así como cómo utilizarlo para escalar el protocolo de consenso actual Jolteon. Jolteon es un protocolo basado en líderes que combina la ruta rápida lineal de Tendermint y el cambio de vista al estilo PBFT, lo que puede reducir la latencia de Hotstuff en un 33%. Sin embargo, los protocolos de consenso basados en líderes claramente no pueden aprovechar completamente el potencial de rendimiento de Narwhal. A pesar de separar la propagación de datos del consenso, a medida que aumenta el rendimiento, el líder de Hotstuff/Jolteon sigue estando limitado.
Por lo tanto, Aptos ha decidido implementar Bullshark sobre el DAG de Narwhal, que es un protocolo de consenso con cero sobrecostos 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.
Contexto de DAG-BFT
Cada vértice en el DAG de Narwhal está asociado con una ronda. Para entrar en la ronda r, los validadores deben primero obtener n-f vértices que pertenecen a la ronda r-1. Cada validador puede difundir 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 es la no ambigüedad: si dos nodos de validación tienen el mismo vértice v en su vista local de DAG, entonces tienen una historia causal de v completamente idéntica.
Prefacio
Se puede alcanzar 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 los bordes 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 (, por ejemplo, en Bullshark, cada dos rondas ) habrá un líder previamente determinado, y el pico del líder se denomina punto de anclaje.
Puntos de anclaje ordenados: los validadores deciden de manera independiente pero determinista qué puntos de anclaje ordenar y cuáles omitir.
Historia causal ordenada: los validadores procesan uno tras otro 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 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, se hacen 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 de sincronización de Bullshark es más práctica y tiene una mejor latencia que la versión asincrónica, aún está lejos de ser ó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 los anclajes; sin embargo, los vértices en la historia causal de los anclajes requieren más rondas para esperar que se ordenen. En casos comunes, los vértices en rondas impares necesitan tres rondas, mientras que los vértices no anclados en rondas pares necesitan cuatro rondas.
Problema 2: latencia de casos de falla. El análisis de latencia anterior se aplica a situaciones sin fallas; por otro lado, si un líder de ronda no logra transmitir los puntos de anclaje lo suficientemente rápido, no se pueden clasificar los puntos de anclaje ( y, por lo tanto, se omiten ). Como resultado, todos los vértices no clasificados en las rondas anteriores deben esperar a que se clasifique el siguiente punto de anclaje. Esto reducirá significativamente el rendimiento de la red de replicación geográfica, especialmente porque Bullshark utiliza un tiempo de espera para esperar al líder.
Marco Shoal
Shoal resolvió estos dos problemas de latencia, mejoró Bullshark( o cualquier otro protocolo BFT basado en Narwhal) mediante el procesamiento en línea, permitiendo que haya un punto de anclaje en cada ronda y reduciendo la latencia de todos los vértices no ancla en el DAG a tres rondas. Shoal también introdujo un mecanismo de reputación de líder 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, el procesamiento en pipeline y la reputación del líder se consideran problemas difíciles, por las siguientes razones:
Los intentos anteriores de procesar en línea intentaron modificar la lógica central de Bullshark, pero esto parece ser esencialmente imposible.
La reputación del líder se introduce en DiemBFT y se formaliza en Carousel, seleccionando dinámicamente a los futuros líderes en función del rendimiento pasado de los validadores, 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 ordenamiento completamente diferente, lo que plantea el núcleo del problema, es decir, que la selección dinámica y determinista del ancla de la ronda 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, la implementación de Bullshark, incluida la que actualmente se encuentra en el entorno de producción, no soporta estas características.
Protocolo
A pesar de los desafíos mencionados, la solución se oculta en la simplicidad.
En Shoal, dependemos de 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 están de acuerdo en el primer punto de anclaje ordenado, Shoal combina secuencialmente múltiples instancias de Bullshark para procesarlas en paralelo, de modo que ) el primer punto de anclaje ordenado es el punto de cambio de las instancias, así como ( la historia causal del punto de anclaje se utiliza para calcular la reputación del líder.
![Explicación detallada del marco Shoal: ¿cómo reducir la latencia de Bullshark en Aptos?])https://img-cdn.gateio.im/webp-social/moments-46d37add0d9e81b2f295edf8eddd907f.webp(
Procesamiento en línea
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á predefinido por el mapeo F. Cada instancia clasifica 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 que se determinó el primer anclaje ordenado, como en la ronda r. Todos los validadores estuvieron de acuerdo con este anclaje. Por lo tanto, todos los validadores pueden acordar con certeza 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. El primer punto de anclaje se ordena según la primera instancia. Luego, Shoal inicia una nueva instancia en la segunda ronda, que tiene su propio punto de anclaje, y ese ancla se ordena por esa instancia, luego, otra nueva instancia ordena un 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-0b0928cb6240e994c1514c75e080a4b2.webp(
Reputación del líder
Al omitir puntos de anclaje durante el ordenamiento de Bullshark, la latencia aumentará. En este caso, la técnica de procesamiento en tubería no puede hacer nada, 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 poco probable que se elija al líder correspondiente para manejar los puntos de anclaje perdidos en el futuro, asignando una puntuación a cada nodo de validación según el historial de actividad reciente de cada nodo. Los validadores que responden y participan en el protocolo recibirán una alta puntuación, de lo contrario, los nodos de validación recibirán una baja puntuación, ya que pueden colapsar, ser lentos o actuar de manera maliciosa.
Su filosofía es recalcular de manera determinista el mapeo predefinido F desde la ronda hasta el líder cada vez que se actualiza la puntuación, inclinándose hacia los líderes con puntuaciones más altas. Para que los validadores lleguen a un consenso sobre el nuevo mapeo, deben llegar a un acuerdo sobre las puntuaciones, logrando así un consenso sobre la historia utilizada para derivar las puntuaciones.
En Shoal, el procesamiento en línea y la reputación del líder pueden combinarse de forma natural, ya que ambos utilizan la misma tecnología central, es decir, 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 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-859e732e16c3eee0e2c93422474debc2.webp(
No hay más tiempo de espera
El tiempo de espera juega un papel crucial en todas las implementaciones BFT deterministas basadas en líderes. Sin embargo, la complejidad que introducen incrementa el número de estados internos que necesitan ser gestionados y observados, lo que aumenta la complejidad del proceso de depuración y requiere más técnicas de observabilidad.
Los tiempos de espera también aumentarán significativamente la latencia, ya que es muy importante configurarlos adecuadamente y a menudo requieren ajustes dinámicos, debido a que dependen en gran medida del entorno ) red (. Antes de pasar al siguiente líder, el protocolo paga una penalización completa por el tiempo de espera del líder defectuoso. 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 omitir a buenos líderes. Por ejemplo, hemos observado que, en condiciones de alta carga, los líderes en Jolteon/Hotstuff están abrumados y el tiempo de espera ha expirado antes de que puedan avanzar.
Desafortunadamente, basado en el protocolo del líder ) como