Marco Shoal: Soltar significativamente la latencia de Bullshark en Aptos
Aptos labs ha resuelto recientemente dos importantes problemas abiertos en DAG BFT, lo que ha reducido significativamente la latencia y, por primera vez, ha eliminado la necesidad de tiempos de espera en protocolos prácticos deterministas. En general, el marco Shoal mejoró la latencia de Bullshark en un 40% en condiciones sin fallos y en un 80% en condiciones con fallos.
Shoal es un marco que mejora cualquier protocolo de consenso basado en Narwhal (, como DAG-Rider, Tusk, Bullshark ), mediante un mecanismo de canalización y reputación del líder. La canalización reduce la latencia de ordenación de DAG al introducir puntos de anclaje en cada ronda, y la reputación del líder mejora aún más la latencia al asegurar que los puntos de anclaje estén asociados con los nodos de validación más rápidos. Además, la reputación del líder permite que Shoal aproveche la construcción de DAG asíncrono para eliminar los tiempos de espera en todos los escenarios. Esto permite que Shoal ofrezca una característica llamada respuesta universal, que incluye la respuesta optimista normalmente requerida.
La idea central de Shoal es muy simple, consiste en ejecutar en orden múltiples instancias del protocolo subyacente. 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 logrado 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 100,000+ TPS.
El reciente avance proviene de reconocer que la propagación de datos es el principal cuello de botella basado en el protocolo de líderes, y que se puede beneficiar a través 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.
En artículos anteriores, presentamos Quorum Store - nuestra implementación de Narwhal, que separa la propagación de datos de la 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 el cambio 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 de la consenso, a medida que aumenta el rendimiento, los líderes de Hotstuff/Jolteon siguen estando limitados.
Por lo tanto, decidimos implementar Bullshark sobre el Narwhal DAG, que es 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%.
Este artículo presenta cómo Shoal logra Soltar significativamente la latencia de Bullshark.
Fondo de DAG-BFT
Cada vértice en el DAG de Narwhal está asociado a 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 característica 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 exactamente la misma historia causal de v.
Prólogo
Se puede llegar a un consenso sobre el orden total de todos los vértices en el DAG sin costos de comunicación adicionales. Para ello, los validadores en DAG-Rider, Tusk y Bullshark interpretan la estructura del DAG como un protocolo de consenso, donde los vértices representan propuestas y las aristas representan votos.
Aunque la lógica de 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 Bullshark, habrá un líder programado en dos rondas ), el pico 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 saltar.
Historial causal ordenado: los validadores procesan uno por uno la lista de puntos de anclaje ordenados, y para cada punto de anclaje, ordenan todos los vértices desordenados anteriores en su historial causal mediante 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 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 parte más práctica de la versión sincronizada de Bullshark 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 punto de anclaje, y los vértices de cada ronda impar se interpretan como votos. 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 se ordenen los puntos de anclaje. 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.
Problema 2: latencia de casos de fallo. 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 lo suficientemente rápido el ancla, no se puede ordenar el ancla (, por lo que se omite ). Por lo tanto, todos los vértices no ordenados en las rondas anteriores deben esperar a que el siguiente ancla sea ordenado. Esto puede Soltar 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 de 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 ancla 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 favorezca a los líderes rápidos.
Desafío
En el contexto del protocolo DAG, la canalización y la reputación del líder se consideran problemas difíciles por las siguientes razones:
Los intentos anteriores de modificar la lógica central de Bullshark en la línea de producción parecían, en esencia, imposibles.
La reputación del líder 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 la discrepancia en la identidad del líder no viola la seguridad de estos protocolos, en Bullshark, puede llevar a un orden completamente diferente, lo que plantea el núcleo del problema, es decir, que seleccionar dinámicamente y de manera determinista el ancla del ciclo es necesario para resolver el consenso, y los validadores necesitan llegar a un acuerdo sobre la historia ordenada para seleccionar el futuro ancla.
Como evidencia de la dificultad del problema, notamos que la implementación de Bullshark, incluida la actualmente en el entorno de producción, no soporta estas características.
Protocolo
A pesar de los desafíos mencionados, la solución se encuentra oculta en la simplicidad.
En Shoal, dependemos de la capacidad de realizar cálculos locales en el DAG y hemos logrado 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 en secuencia múltiples instancias de Bullshark para procesarlas en paralelo, lo que hace que ) el primer ancla ordenada sea el punto de conmutación de las instancias, así como ( la historia causal de los anclajes se utiliza para calcular la reputación del líder.
![Explicación detallada del marco Shoal: ¿Cómo Soltar la latencia de Bullshark en Aptos?])https://img-cdn.gateio.im/webp-social/moments-46d37add0d9e81b2f295edf8eddd907f.webp(
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 está predefinido por el mapeo F. Cada instancia ordena un ancla, lo que activa 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 aceptaron este ancla. Por lo tanto, todos los validadores pueden acordar de manera definitiva 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 punto de anclaje de la primera ronda se ordena según 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, luego, otra nueva instancia ordena el punto de anclaje en la tercera ronda, y luego el proceso continúa.
![Explicación detallada del marco Shoal: ¿cómo reducir la latencia de Bullshark en Aptos?])https://img-cdn.gateio.im/webp-social/moments-0b0928cb6240e994c1514c75e080a4b2.webp(
Reputación del líder
Durante el ordenamiento de Bullshark, al saltar puntos de anclaje, la latencia aumentará. En este caso, la técnica de tubería 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 poco probable que se elijan líderes correspondientes 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 respondan y participen en el protocolo recibirán altas puntuaciones; de lo contrario, los nodos de validación recibirán bajas puntuaciones, ya que pueden estar fallando, siendo lentos o actuando maliciosamente.
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, favoreciendo a los líderes con puntajes más altos. Para que los validadores lleguen a un consenso sobre el nuevo mapeo, deben alcanzar un consenso sobre los puntajes, logrando así un acuerdo sobre la historia utilizada para derivar los puntajes.
En Shoal, la línea de producción y la reputación del liderazgo pueden combinarse de manera natural, ya que ambas utilizan la misma tecnología central, es decir, reinterpretar el DAG después de llegar a un consenso sobre el primer punto de anclaje ordenado.
De hecho, la única diferencia es que, después de ordenar los puntos de anclaje en la ronda r, el validador solo necesita 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 Soltar 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 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, necesitan ajustes dinámicos, ya que dependen en gran medida del entorno ) red (. Antes de pasar al siguiente líder, el protocolo pagará la penalización completa por la latencia del líder con fallos. Por lo tanto, la configuración del tiempo de espera no puede ser demasiado conservadora, pero si el tiempo de espera es demasiado corto, el protocolo puede omitir a buenos líderes. Por ejemplo, hemos observado que, en situaciones de alta carga, los líderes en Jolteon/Hotstuff se ven abrumados y el tiempo de espera ya ha expirado antes de que puedan impulsar el progreso.
Desafortunadamente, el protocolo basado en el líder ) como Hotstuff
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
10
Republicar
Compartir
Comentar
0/400
TokenomicsTrapper
· 07-16 23:24
clásico vc humo y espejos... el 40% no significa nada si la latencia base fue basura, para ser honesto
Ver originalesResponder0
rekt_but_resilient
· 07-16 17:01
¿La latencia disminuyó un 80%? ¡To the moon!
Ver originalesResponder0
NestedFox
· 07-16 09:09
La mejora de ochenta grados es increíble.
Ver originalesResponder0
Blockwatcher9000
· 07-15 13:37
Todavía superando la latencia, ¡fuerte!
Ver originalesResponder0
GasFeePhobia
· 07-14 02:57
¿40 no es demasiado fuerte? El efecto es bueno.
Ver originalesResponder0
MEVHunterBearish
· 07-14 02:55
¿De qué sirve esto? Nosotros somos alcistas, no bajistas.
Ver originalesResponder0
WalletsWatcher
· 07-14 02:55
Ah, por fin se resolvió la latencia.
Ver originalesResponder0
CryptoFortuneTeller
· 07-14 02:45
Compra aptos compra aptos ya casi no quedan
Ver originalesResponder0
MetamaskMechanic
· 07-14 02:43
Inicio de sesión, alguien más ha optimizado la latencia.
El marco Shoal reduce significativamente la latencia de Bullshark en Aptos, logrando un consenso de determinación sin tiempo de espera.
Marco Shoal: Soltar significativamente la latencia de Bullshark en Aptos
Aptos labs ha resuelto recientemente dos importantes problemas abiertos en DAG BFT, lo que ha reducido significativamente la latencia y, por primera vez, ha eliminado la necesidad de tiempos de espera en protocolos prácticos deterministas. En general, el marco Shoal mejoró la latencia de Bullshark en un 40% en condiciones sin fallos y en un 80% en condiciones con fallos.
Shoal es un marco que mejora cualquier protocolo de consenso basado en Narwhal (, como DAG-Rider, Tusk, Bullshark ), mediante un mecanismo de canalización y reputación del líder. La canalización reduce la latencia de ordenación de DAG al introducir puntos de anclaje en cada ronda, y la reputación del líder mejora aún más la latencia al asegurar que los puntos de anclaje estén asociados con los nodos de validación más rápidos. Además, la reputación del líder permite que Shoal aproveche la construcción de DAG asíncrono para eliminar los tiempos de espera en todos los escenarios. Esto permite que Shoal ofrezca una característica llamada respuesta universal, que incluye la respuesta optimista normalmente requerida.
La idea central de Shoal es muy simple, consiste en ejecutar en orden múltiples instancias del protocolo subyacente. 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 logrado 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 100,000+ TPS.
El reciente avance proviene de reconocer que la propagación de datos es el principal cuello de botella basado en el protocolo de líderes, y que se puede beneficiar a través 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.
En artículos anteriores, presentamos Quorum Store - nuestra implementación de Narwhal, que separa la propagación de datos de la 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 el cambio 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 de la consenso, a medida que aumenta el rendimiento, los líderes de Hotstuff/Jolteon siguen estando limitados.
Por lo tanto, decidimos implementar Bullshark sobre el Narwhal DAG, que es 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%.
Este artículo presenta cómo Shoal logra Soltar significativamente la latencia de Bullshark.
Fondo de DAG-BFT
Cada vértice en el DAG de Narwhal está asociado a 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 característica 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 exactamente la misma historia causal de v.
Prólogo
Se puede llegar a un consenso sobre el orden total de todos los vértices en el DAG sin costos de comunicación adicionales. Para ello, los validadores en DAG-Rider, Tusk y Bullshark interpretan la estructura del DAG como un protocolo de consenso, donde los vértices representan propuestas y las aristas representan votos.
Aunque la lógica de 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 Bullshark, habrá un líder programado en dos rondas ), el pico 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 saltar.
Historial causal ordenado: los validadores procesan uno por uno la lista de puntos de anclaje ordenados, y para cada punto de anclaje, ordenan todos los vértices desordenados anteriores en su historial causal mediante 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 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 parte más práctica de la versión sincronizada de Bullshark 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 punto de anclaje, y los vértices de cada ronda impar se interpretan como votos. 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 se ordenen los puntos de anclaje. 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.
Problema 2: latencia de casos de fallo. 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 lo suficientemente rápido el ancla, no se puede ordenar el ancla (, por lo que se omite ). Por lo tanto, todos los vértices no ordenados en las rondas anteriores deben esperar a que el siguiente ancla sea ordenado. Esto puede Soltar 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 de 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 ancla 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 favorezca a los líderes rápidos.
Desafío
En el contexto del protocolo DAG, la canalización y la reputación del líder se consideran problemas difíciles por las siguientes razones:
Los intentos anteriores de modificar la lógica central de Bullshark en la línea de producción parecían, en esencia, imposibles.
La reputación del líder 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 la discrepancia en la identidad del líder no viola la seguridad de estos protocolos, en Bullshark, puede llevar a un orden completamente diferente, lo que plantea el núcleo del problema, es decir, que seleccionar dinámicamente y de manera determinista el ancla del ciclo es necesario para resolver el consenso, y los validadores necesitan llegar a un acuerdo sobre la historia ordenada para seleccionar el futuro ancla.
Como evidencia de la dificultad del problema, notamos que la implementación de Bullshark, incluida la actualmente en el entorno de producción, no soporta estas características.
Protocolo
A pesar de los desafíos mencionados, la solución se encuentra oculta en la simplicidad.
En Shoal, dependemos de la capacidad de realizar cálculos locales en el DAG y hemos logrado 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 en secuencia múltiples instancias de Bullshark para procesarlas en paralelo, lo que hace que ) el primer ancla ordenada sea el punto de conmutación de las instancias, así como ( la historia causal de los anclajes se utiliza para calcular la reputación del líder.
![Explicación detallada del marco Shoal: ¿Cómo Soltar la latencia de Bullshark en Aptos?])https://img-cdn.gateio.im/webp-social/moments-46d37add0d9e81b2f295edf8eddd907f.webp(
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 está predefinido por el mapeo F. Cada instancia ordena un ancla, lo que activa 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 aceptaron este ancla. Por lo tanto, todos los validadores pueden acordar de manera definitiva 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 punto de anclaje de la primera ronda se ordena según 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, luego, otra nueva instancia ordena el punto de anclaje en la tercera ronda, y luego el proceso continúa.
![Explicación detallada del marco Shoal: ¿cómo reducir la latencia de Bullshark en Aptos?])https://img-cdn.gateio.im/webp-social/moments-0b0928cb6240e994c1514c75e080a4b2.webp(
Reputación del líder
Durante el ordenamiento de Bullshark, al saltar puntos de anclaje, la latencia aumentará. En este caso, la técnica de tubería 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 poco probable que se elijan líderes correspondientes 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 respondan y participen en el protocolo recibirán altas puntuaciones; de lo contrario, los nodos de validación recibirán bajas puntuaciones, ya que pueden estar fallando, siendo lentos o actuando maliciosamente.
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, favoreciendo a los líderes con puntajes más altos. Para que los validadores lleguen a un consenso sobre el nuevo mapeo, deben alcanzar un consenso sobre los puntajes, logrando así un acuerdo sobre la historia utilizada para derivar los puntajes.
En Shoal, la línea de producción y la reputación del liderazgo pueden combinarse de manera natural, ya que ambas utilizan la misma tecnología central, es decir, reinterpretar el DAG después de llegar a un consenso sobre el primer punto de anclaje ordenado.
De hecho, la única diferencia es que, después de ordenar los puntos de anclaje en la ronda r, el validador solo necesita 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 Soltar 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 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, necesitan ajustes dinámicos, ya que dependen en gran medida del entorno ) red (. Antes de pasar al siguiente líder, el protocolo pagará la penalización completa por la latencia del líder con fallos. Por lo tanto, la configuración del tiempo de espera no puede ser demasiado conservadora, pero si el tiempo de espera es demasiado corto, el protocolo puede omitir a buenos líderes. Por ejemplo, hemos observado que, en situaciones de alta carga, los líderes en Jolteon/Hotstuff se ven abrumados y el tiempo de espera ya ha expirado antes de que puedan impulsar el progreso.
Desafortunadamente, el protocolo basado en el líder ) como Hotstuff