Marco Shoal: ¿Cómo reducir la latencia de Bullshark en Aptos?
Resumen
Aptos labs resolvió dos importantes problemas abiertos en DAG BFT, reduciendo drásticamente la latencia y eliminando por primera vez la necesidad de pausas en protocolos prácticos deterministas. En general, 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 el procesamiento en línea y un mecanismo de reputación del líder. La línea de producción reduce la latencia de ordenamiento 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 los nodos de validación más rápidos. Además, la reputación del líder permite que Shoal utilice construcciones de DAG asíncronas para eliminar los tiempos de espera en todos los escenarios. Esto permite que Shoal ofrezca lo que llamamos la propiedad de respuesta universal, que incluye la respuesta optimista que normalmente se requiere.
La tecnología es muy simple, implica ejecutar múltiples instancias del protocolo subyacente una tras otra en orden. Por lo tanto, cuando se instancia con Bullshark, obtenemos un grupo de "tiburones" que están en una carrera de relevos.
Motivación
Al perseguir un alto rendimiento en redes blockchain, la gente ha estado enfocada en reducir la complejidad de la comunicación. Sin embargo, este enfoque no ha logrado un aumento significativo en el rendimiento. Por ejemplo, Hotstuff implementado en las primeras versiones de Diem solo alcanzó 3500 TPS, muy por debajo del objetivo de 100k+ TPS.
El reciente avance se debe a 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 se puede beneficiar 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 una capacidad de 160,000 TPS.
El Quorum Store, presentado anteriormente, es una implementación de Narwhal que separa la propagación de datos del consenso, utilizado 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 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, se decidió desplegar Bullshark sobre el DAG Narwhal, que es un protocolo de consenso sin costos 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 reduce significativamente la latencia de Bullshark.
Antecedentes de DAG-BFT
Cada vértice en el DAG de Narwhal está asociado con un número de 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 característica 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.
Orden total
Se puede lograr 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 las propuestas y las aristas representan los 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 habrá un líder predefinido, y el punto más alto 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 causal ordenada: los validadores procesan uno a uno la lista de puntos de anclaje ordenados, ordenando todos los vértices desordenados anteriores en la historia causal de cada punto de anclaje.
La clave para satisfacer la seguridad es asegurar que en el paso (2), todos los nodos de verificación honestos compartan la misma prefijo en la lista de puntos de anclaje ordenados que crean. En Shoal, hacemos las siguientes observaciones sobre todos los protocolos mencionados anteriormente:
Todos los validadores están de acuerdo con el primer punto de anclaje ordenado.
Bullshark retraso
La latencia de Bullshark depende del número de rondas entre los anclajes ordenados en el DAG. Aunque la versión sincronizada de Bullshark es más práctica y tiene una mejor latencia que la versión asíncrona, todavía está lejos de ser la óptima.
Pregunta 1: Retraso medio de bloque. En Bullshark, cada ronda par tiene un punto de anclaje, mientras que el vértice de cada ronda impar se interpreta como un voto. En situaciones comunes, se requieren dos rondas de DAG para ordenar los puntos de anclaje; sin embargo, los vértices en la historia causal de los puntos de anclaje requieren más rondas para esperar que los puntos de anclaje sean ordenados. En situaciones comunes, los vértices en rondas impares requieren tres rondas, mientras que los vértices no anclados en rondas pares requieren cuatro rondas.
Pregunta 2: Retraso en los casos de fallo. El análisis de retraso anterior se aplica a situaciones sin fallos; por otro lado, si un líder de ronda no transmite lo suficientemente rápido el punto de anclaje, no se puede clasificar el punto de anclaje (, por lo tanto se omite ), lo que significa que todos los vértices no clasificados de las rondas anteriores deben esperar a que el siguiente punto de anclaje sea clasificado. 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 ha mejorado el Bullshark( o cualquier otro protocolo BFT basado en Narwhal) mediante el procesamiento en línea, permitiendo 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 ha introducido un mecanismo de reputación de líderes 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, el procesamiento en pipeline 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 parecen ser esencialmente imposibles.
La reputación del líder se introduce en DiemBFT y se formaliza en Carousel, seleccionando dinámicamente a futuros líderes según el rendimiento pasado de los validadores, la idea de un ancla en Bullshark (. Aunque las discrepancias en la identidad del líder no violan la seguridad de estos protocolos, en Bullshark, podrían resultar en un orden completamente diferente, lo que plantea el núcleo del problema: seleccionar anclas de manera dinámica y determinista es esencial para resolver el consenso, y los validadores deben llegar a un acuerdo sobre la historia ordenada para seleccionar futuros anclas.
Como evidencia de la dificultad del problema, notamos que la implementación de Bullshark, incluida la que actualmente está en producción, no soporta 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-0b0928cb6240e994c1514c75e080a4b2.webp(
Protocolo
A pesar de los desafíos mencionados, la solución se oculta en la sencillez.
En Shoal, confiamos en la capacidad de realizar cálculos locales sobre DAG y hemos logrado guardar y reinterpretar la información de rondas anteriores. Con la idea central de que todos los validadores acuerdan el primer ancla ordenada, Shoal combina secuencialmente múltiples instancias de Bullshark para procesarlas en línea, haciendo que ) el primer ancla ordenada sea el punto de cambio de las instancias, y ( la historia causal de las anclas se utilice para calcular la reputación de los líderes.
Manejo de línea de producción
V que mapea las rondas a los líderes. Shoal ejecuta instancias de Bullshark una tras otra, de tal manera que para cada instancia, el ancla está predefinido por el mapeo F. Cada instancia ordena un ancla, lo que desencadena el cambio a la siguiente instancia.
Inicialmente, Shoal lanzó la primera instancia de Bullshark en la primera ronda de DAG y la ejecutó hasta que se determinó el primer ancla ordenada, como en la ronda r. Todos los validadores acordaron este ancla. Por lo tanto, todos los validadores pueden acordar con certeza reinterpretar el DAG a partir de la ronda r+1. Shoal solo lanzó una nueva instancia de Bullshark en la ronda r+1.
En el mejor de los casos, esto permite que Shoal ordene un ancla en cada ronda. Los puntos de ancla de la primera ronda se ordenan por la primera instancia. Luego, Shoal comienza una nueva instancia en la segunda ronda, que tiene su propio punto de ancla, el cual es ordenado por dicha instancia; luego, otra nueva instancia ordena el punto de ancla 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 período de clasificación de Bullshark, omitir los puntos de anclaje aumentará la latencia. En este caso, la técnica de procesamiento en línea no puede ayudar, ya que no se puede iniciar una nueva instancia antes de que se ordene el punto de anclaje del anterior. Shoal asegura que es menos probable que se elija a los 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 una alta puntuación; de lo contrario, a los nodos de validación se les asignará una puntuación baja, ya que pueden fallar, ser lentos o actuar de manera maliciosa.
Su concepto es recalcular de manera determinista el mapeo predefinido F desde la ronda al 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 llegar a un consenso sobre los puntajes, logrando así un consenso en la historia utilizada para derivar los puntajes.
En Shoal, el procesamiento en línea y la reputación del líder pueden combinarse de manera natural, ya que ambos 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 anclajes en la ronda r, el validador solo necesita calcular un nuevo mapeo F' a partir de la historia causal de los anclajes ordenados en la ronda r, comenzando desde la ronda r+1. Luego, los nodos validadores comienzan a ejecutar una nueva instancia de Bullshark utilizando la función de selección de anclajes actualizada F' a partir de la ronda r+1.
![Explicación detallada de Shoal Framework: ¿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 de BFT deterministas basadas en líderes. Sin embargo, la complejidad que introducen aumenta el número 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.
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, 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 de tiempo de espera para el líder con fallos. Por lo tanto, la configuración de los tiempos 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, observamos que, en condiciones de alta carga, los líderes en Jolteon/Hotstuff estaban abrumados y agotaron el tiempo de espera antes de que pudieran impulsar el progreso.
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.
21 me gusta
Recompensa
21
9
Compartir
Comentar
0/400
RektCoaster
· 08-03 07:00
¿La latencia ha bajado tanto? ¡Alcista!
Ver originalesResponder0
Degen4Breakfast
· 08-02 20:25
Está bien, no hace falta complicarse tanto para ser un ancla.
Ver originalesResponder0
SatoshiLegend
· 08-02 17:14
Aunque la optimización de DAG es buena, no cambiar la intención original es la clave para el éxito. No hay secretos bajo el código fuente.
Ver originalesResponder0
NonFungibleDegen
· 08-01 16:37
alcista af en aptos rn... 80% más rápido? probablemente nada ser
Ver originalesResponder0
Ser_This_Is_A_Casino
· 07-31 12:48
Reducir la latencia puede llevar a esto.
Ver originalesResponder0
BearMarketBro
· 07-31 12:48
Parece bastante bien.
Ver originalesResponder0
ApeShotFirst
· 07-31 12:25
¡Vaya, Aptos ha hecho algo nuevo!
Ver originalesResponder0
GasFeeCrybaby
· 07-31 12:25
¿Cuándo podrá bajar la tarifa de gas?
Ver originalesResponder0
ImpermanentLossFan
· 07-31 12:24
Finalmente alguien se acordó de mis Acciones tipo A Aptos.
El marco Shoal mejora significativamente el rendimiento de Bullshark en la cadena Aptos, reduciendo la latencia hasta un 80%.
Marco Shoal: ¿Cómo reducir la latencia de Bullshark en Aptos?
Resumen
Aptos labs resolvió dos importantes problemas abiertos en DAG BFT, reduciendo drásticamente la latencia y eliminando por primera vez la necesidad de pausas en protocolos prácticos deterministas. En general, 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 el procesamiento en línea y un mecanismo de reputación del líder. La línea de producción reduce la latencia de ordenamiento 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 los nodos de validación más rápidos. Además, la reputación del líder permite que Shoal utilice construcciones de DAG asíncronas para eliminar los tiempos de espera en todos los escenarios. Esto permite que Shoal ofrezca lo que llamamos la propiedad de respuesta universal, que incluye la respuesta optimista que normalmente se requiere.
La tecnología es muy simple, implica ejecutar múltiples instancias del protocolo subyacente una tras otra en orden. Por lo tanto, cuando se instancia con Bullshark, obtenemos un grupo de "tiburones" que están en una carrera de relevos.
Motivación
Al perseguir un alto rendimiento en redes blockchain, la gente ha estado enfocada en reducir la complejidad de la comunicación. Sin embargo, este enfoque no ha logrado un aumento significativo en el rendimiento. Por ejemplo, Hotstuff implementado en las primeras versiones de Diem solo alcanzó 3500 TPS, muy por debajo del objetivo de 100k+ TPS.
El reciente avance se debe a 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 se puede beneficiar 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 una capacidad de 160,000 TPS.
El Quorum Store, presentado anteriormente, es una implementación de Narwhal que separa la propagación de datos del consenso, utilizado 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 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, se decidió desplegar Bullshark sobre el DAG Narwhal, que es un protocolo de consenso sin costos 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 reduce significativamente la latencia de Bullshark.
Antecedentes de DAG-BFT
Cada vértice en el DAG de Narwhal está asociado con un número de 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 característica 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.
Orden total
Se puede lograr 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 las propuestas y las aristas representan los 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 habrá un líder predefinido, y el punto más alto 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 causal ordenada: los validadores procesan uno a uno la lista de puntos de anclaje ordenados, ordenando todos los vértices desordenados anteriores en la historia causal de cada punto de anclaje.
La clave para satisfacer la seguridad es asegurar que en el paso (2), todos los nodos de verificación honestos compartan la misma prefijo en la lista de puntos de anclaje ordenados que crean. En Shoal, hacemos las siguientes observaciones sobre todos los protocolos mencionados anteriormente:
Todos los validadores están de acuerdo con el primer punto de anclaje ordenado.
Bullshark retraso
La latencia de Bullshark depende del número de rondas entre los anclajes ordenados en el DAG. Aunque la versión sincronizada de Bullshark es más práctica y tiene una mejor latencia que la versión asíncrona, todavía está lejos de ser la óptima.
Pregunta 1: Retraso medio de bloque. En Bullshark, cada ronda par tiene un punto de anclaje, mientras que el vértice de cada ronda impar se interpreta como un voto. En situaciones comunes, se requieren dos rondas de DAG para ordenar los puntos de anclaje; sin embargo, los vértices en la historia causal de los puntos de anclaje requieren más rondas para esperar que los puntos de anclaje sean ordenados. En situaciones comunes, los vértices en rondas impares requieren tres rondas, mientras que los vértices no anclados en rondas pares requieren cuatro rondas.
Pregunta 2: Retraso en los casos de fallo. El análisis de retraso anterior se aplica a situaciones sin fallos; por otro lado, si un líder de ronda no transmite lo suficientemente rápido el punto de anclaje, no se puede clasificar el punto de anclaje (, por lo tanto se omite ), lo que significa que todos los vértices no clasificados de las rondas anteriores deben esperar a que el siguiente punto de anclaje sea clasificado. 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 ha mejorado el Bullshark( o cualquier otro protocolo BFT basado en Narwhal) mediante el procesamiento en línea, permitiendo 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 ha introducido un mecanismo de reputación de líderes 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, el procesamiento en pipeline 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 parecen ser esencialmente imposibles.
La reputación del líder se introduce en DiemBFT y se formaliza en Carousel, seleccionando dinámicamente a futuros líderes según el rendimiento pasado de los validadores, la idea de un ancla en Bullshark (. Aunque las discrepancias en la identidad del líder no violan la seguridad de estos protocolos, en Bullshark, podrían resultar en un orden completamente diferente, lo que plantea el núcleo del problema: seleccionar anclas de manera dinámica y determinista es esencial para resolver el consenso, y los validadores deben llegar a un acuerdo sobre la historia ordenada para seleccionar futuros anclas.
Como evidencia de la dificultad del problema, notamos que la implementación de Bullshark, incluida la que actualmente está en producción, no soporta 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-0b0928cb6240e994c1514c75e080a4b2.webp(
Protocolo
A pesar de los desafíos mencionados, la solución se oculta en la sencillez.
En Shoal, confiamos en la capacidad de realizar cálculos locales sobre DAG y hemos logrado guardar y reinterpretar la información de rondas anteriores. Con la idea central de que todos los validadores acuerdan el primer ancla ordenada, Shoal combina secuencialmente múltiples instancias de Bullshark para procesarlas en línea, haciendo que ) el primer ancla ordenada sea el punto de cambio de las instancias, y ( la historia causal de las anclas se utilice para calcular la reputación de los líderes.
Manejo de línea de producción
V que mapea las rondas a los líderes. Shoal ejecuta instancias de Bullshark una tras otra, de tal manera que para cada instancia, el ancla está predefinido por el mapeo F. Cada instancia ordena un ancla, lo que desencadena el cambio a la siguiente instancia.
Inicialmente, Shoal lanzó la primera instancia de Bullshark en la primera ronda de DAG y la ejecutó hasta que se determinó el primer ancla ordenada, como en la ronda r. Todos los validadores acordaron este ancla. Por lo tanto, todos los validadores pueden acordar con certeza reinterpretar el DAG a partir de la ronda r+1. Shoal solo lanzó una nueva instancia de Bullshark en la ronda r+1.
En el mejor de los casos, esto permite que Shoal ordene un ancla en cada ronda. Los puntos de ancla de la primera ronda se ordenan por la primera instancia. Luego, Shoal comienza una nueva instancia en la segunda ronda, que tiene su propio punto de ancla, el cual es ordenado por dicha instancia; luego, otra nueva instancia ordena el punto de ancla 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 período de clasificación de Bullshark, omitir los puntos de anclaje aumentará la latencia. En este caso, la técnica de procesamiento en línea no puede ayudar, ya que no se puede iniciar una nueva instancia antes de que se ordene el punto de anclaje del anterior. Shoal asegura que es menos probable que se elija a los 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 una alta puntuación; de lo contrario, a los nodos de validación se les asignará una puntuación baja, ya que pueden fallar, ser lentos o actuar de manera maliciosa.
Su concepto es recalcular de manera determinista el mapeo predefinido F desde la ronda al 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 llegar a un consenso sobre los puntajes, logrando así un consenso en la historia utilizada para derivar los puntajes.
En Shoal, el procesamiento en línea y la reputación del líder pueden combinarse de manera natural, ya que ambos 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 anclajes en la ronda r, el validador solo necesita calcular un nuevo mapeo F' a partir de la historia causal de los anclajes ordenados en la ronda r, comenzando desde la ronda r+1. Luego, los nodos validadores comienzan a ejecutar una nueva instancia de Bullshark utilizando la función de selección de anclajes actualizada F' a partir de la ronda r+1.
![Explicación detallada de Shoal Framework: ¿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 de BFT deterministas basadas en líderes. Sin embargo, la complejidad que introducen aumenta el número 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.
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, 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 de tiempo de espera para el líder con fallos. Por lo tanto, la configuración de los tiempos 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, observamos que, en condiciones de alta carga, los líderes en Jolteon/Hotstuff estaban abrumados y agotaron el tiempo de espera antes de que pudieran impulsar el progreso.