Marco Shoal: Soltar la latencia de Bullshark en Aptos
Aptos Labs ha resuelto recientemente dos importantes problemas abiertos en DAG BFT, lo que ha permitido Soltar la latencia de manera significativa y ha eliminado por primera vez la necesidad de tiempos de espera en un protocolo práctico determinista. En general, se mejoró la latencia de Bullshark en un 40% en condiciones sin fallos y en un 80% en condiciones de fallo.
Shoal es un marco que mejora cualquier protocolo de consenso basado en Narwhal (, como DAG-Rider, Tusk, Bullshark ), a través de la canalización y la reputación de líderes. La canalizació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 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 a Shoal aprovechar la construcción de DAG asíncrono para eliminar los tiempos de espera en todos los escenarios. Esto permite que Shoal ofrezca lo que se llama capacidad de respuesta universal, que incluye la capacidad de respuesta optimista que normalmente se requiere.
Esta tecnología es bastante simple, implica ejecutar múltiples instancias del protocolo subyacente en orden. Por lo tanto, cuando se instancia con Bullshark, obtenemos un grupo de "tiburones" que están participando en una carrera de relevos.
Motivación
Al buscar un alto rendimiento en la red blockchain, la gente ha estado enfocada en Soltar la complejidad de la comunicación. Sin embargo, este enfoque no ha conducido a un aumento significativo en el rendimiento. Por ejemplo, Hotstuff implementado en las versiones tempranas de Diem solo logró 3500 TPS, muy por debajo de nuestro objetivo de lograr más de 100k 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 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 donde todos los validadores propagan datos simultáneamente, y el componente de consenso solo ordena una pequeña cantidad de metadatos. El documento de Narwhal informa de un rendimiento de 160,000 TPS.
En artículos anteriores, presentamos Quorum Store. Nuestra implementación de Narwhal separa la propagación de datos del consenso, así como cómo 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 Soltar la latencia de Hotstuff en un 33%. Sin embargo, es evidente que los protocolos de consenso basados en líderes no pueden aprovechar plenamente el potencial de rendimiento de Narwhal. A pesar de separar la propagación de datos del consenso, a medida que aumenta el rendimiento, el líder de Hotstuff/Jolteon sigue estando limitado.
Por lo tanto, decidimos desplegar Bullshark sobre Narwhal DAG, un protocolo de consenso con costo de comunicación cero. 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 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 difundir un vértice por ronda, y cada vértice hace referencia a 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 del DAG es que no es difusa: si dos nodos de validación tienen el mismo vértice v en su vista local del DAG, entonces tienen exactamente la misma historia causal de v.
Prefacio
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 los bordes representan votos.
Aunque la lógica de intersección de grupos en la estructura DAG es diferente, todos los protocolos de consenso existentes basados en Narwhal tienen la siguiente estructura:
Punto de anclaje reservado: cada ciertas rondas (, por ejemplo, en Bullshark, cada dos rondas ) hay un líder previamente determinado, y el punto culminante del líder se llama punto de anclaje;
Puntos de anclaje ordenados: los validadores deciden de manera independiente pero determinista cuáles anclajes ordenar y cuáles saltar;
Historia causal ordenada: los validadores procesan uno a uno la lista de anclajes ordenados, y para cada anclaje, ordenan todos los vértices desordenados anteriores en su historia causal a través de algunas reglas deterministas.
La clave para cumplir con 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 están de acuerdo con 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 Bullshark, la versión sincronizada, tiene mejor latencia que la versión asincrónica, está lejos de ser la óptima.
Pregunta 1: latencia media de bloques. En Bullshark, cada ronda par tiene un ancla, y los vértices de cada ronda impar se interpretan como votos. En situaciones comunes, se requieren dos rondas de DAG para ordenar los anclajes; sin embargo, los vértices en la historia causal del ancla requieren más rondas para esperar que el ancla sea ordenada. En situaciones comunes, los vértices en rondas impares requieren tres rondas, mientras que los vértices no ancla en rondas pares requieren cuatro rondas.
Pregunta 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 en una ronda no logra transmitir el ancla lo suficientemente rápido, no se puede ordenar el ancla (, por lo que se omite ). Por lo tanto, todos los vértices no ordenados en las primeras rondas deben esperar a que se ordene el siguiente ancla. 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 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íderes de costo cero en el DAG, lo que hace que la selección se incline hacia líderes rápidos.
Desafío
En el contexto del protocolo DAG, la 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 los futuros líderes en función del rendimiento pasado de los validadores en la idea de ancla en Bullshark (. Aunque las discrepancias en la identidad del líder no violan la seguridad de estos protocolos, en Bullshark, puede dar lugar a ordenaciones completamente diferentes, lo que plantea el núcleo del problema, es decir, que seleccionar de manera dinámica y determinista el ancla de la ronda es esencial para resolver el consenso, y los validadores necesitan llegar a un acuerdo sobre la historia ordenada para elegir futuros anclas.
Como evidencia de la dificultad del problema, notamos que la implementación de Bullshark, incluida la que actualmente se utiliza en el entorno de producción, no admite estas características.
Protocolo
A pesar de los desafíos mencionados, la solución se encuentra escondida en la simplicidad.
En Shoal, confiamos en la capacidad de ejecutar cálculos locales sobre DAG y logramos 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 con el primer punto de anclaje ordenado, Shoal combina secuencialmente múltiples instancias de Bullshark para procesarlas en línea, 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 de los líderes.
![Explicación detallada del marco Shoal: ¿Cómo Soltar la latencia de Bullshark en Aptos?])https://img-cdn.gateio.im/webp-social/moments-0b0928cb6240e994c1514c75e080a4b2.webp(
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á predefinida por el mapeo F. Cada instancia solicita 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 punto de anclaje ordenado, como en la ronda r. Todos los validadores estuvieron de acuerdo con 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 lanzó una nueva instancia de Bullshark en la ronda r+1.
En el mejor de los casos, esto permite a Shoal pedir un ancla en cada ronda. Los puntos de anclaje de la primera ronda se ordenan 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, y luego, otra nueva instancia pide un punto de anclaje en la tercera ronda, y así continúa el proceso.
![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 la ordenación de Bullshark, al omitir los puntos de anclaje, la latencia aumentará. En este caso, la técnica de canalización es inútil, ya que no se puede iniciar una nueva instancia antes de que se ordenen los puntos de anclaje de la instancia anterior. Shoal asegura que en el futuro sea menos probable que se elijan los líderes correspondientes para manejar los puntos de anclaje perdidos, asignando un puntaje a cada nodo de validación según la historia de actividad reciente de cada nodo de validación mediante el uso de un mecanismo de reputación. Los validadores que respondan y participen 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 estar caídos, lentos o actuar mal.
Su concepto es recalcular de manera determinista el mapeo predefinido F de cada ronda al líder en cada actualización de 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 alcanzar un consenso sobre las puntuaciones, logrando así un acuerdo en la historia utilizada para derivar las puntuaciones.
En Shoal, la cadena de bloques y la reputación del líder pueden combinarse de forma natural, ya que ambas utilizan la misma tecnología central, es decir, 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 Soltar la latencia de Bullshark en Aptos?])https://img-cdn.gateio.im/webp-social/moments-9f789cb669f6fcc244ea7ff7648e48b4.webp(
No hay más tiempo de espera
El tiempo de espera juega un papel crucial en todas las implementaciones BFT determinísticas basadas en líder. 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 requiere ajustes dinámicos, ya que depende en gran medida del entorno ) red (. Antes de pasar al siguiente líder, el protocolo pagará una penalización completa por la latencia de 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 saltarse a un buen líder. Por ejemplo, observamos que, en condiciones de alta carga, Jolteon/
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.
22 me gusta
Recompensa
22
5
Republicar
Compartir
Comentar
0/400
BlockchainFries
· 07-21 02:44
Espera, ¿40% y 80%? ¿Está seguro de que no está hablando de ilusiones?
Ver originalesResponder0
YouMustMakeBigMoneyEvery
· 07-20 12:23
Aún no ha emprendido un esfuerzo decidido. Está demasiado mal. Romper 6 yuanes para aumentar la posición.
Ver originalesResponder0
HalfBuddhaMoney
· 07-20 09:59
La latencia ha bajado tanto, aptos es digno de esperar.
Ver originalesResponder0
SleepyArbCat
· 07-20 09:58
Ya casi amanece y aptos finalmente emprende un esfuerzo decidido... si la latencia baja un poco más, podré conseguir algo de comer.
El marco Shoal Soltar Aptos Bullshark latencia 40%-80%
Marco Shoal: Soltar la latencia de Bullshark en Aptos
Aptos Labs ha resuelto recientemente dos importantes problemas abiertos en DAG BFT, lo que ha permitido Soltar la latencia de manera significativa y ha eliminado por primera vez la necesidad de tiempos de espera en un protocolo práctico determinista. En general, se mejoró la latencia de Bullshark en un 40% en condiciones sin fallos y en un 80% en condiciones de fallo.
Shoal es un marco que mejora cualquier protocolo de consenso basado en Narwhal (, como DAG-Rider, Tusk, Bullshark ), a través de la canalización y la reputación de líderes. La canalizació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 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 a Shoal aprovechar la construcción de DAG asíncrono para eliminar los tiempos de espera en todos los escenarios. Esto permite que Shoal ofrezca lo que se llama capacidad de respuesta universal, que incluye la capacidad de respuesta optimista que normalmente se requiere.
Esta tecnología es bastante simple, implica ejecutar múltiples instancias del protocolo subyacente en orden. Por lo tanto, cuando se instancia con Bullshark, obtenemos un grupo de "tiburones" que están participando en una carrera de relevos.
Motivación
Al buscar un alto rendimiento en la red blockchain, la gente ha estado enfocada en Soltar la complejidad de la comunicación. Sin embargo, este enfoque no ha conducido a un aumento significativo en el rendimiento. Por ejemplo, Hotstuff implementado en las versiones tempranas de Diem solo logró 3500 TPS, muy por debajo de nuestro objetivo de lograr más de 100k 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 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 donde todos los validadores propagan datos simultáneamente, y el componente de consenso solo ordena una pequeña cantidad de metadatos. El documento de Narwhal informa de un rendimiento de 160,000 TPS.
En artículos anteriores, presentamos Quorum Store. Nuestra implementación de Narwhal separa la propagación de datos del consenso, así como cómo 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 Soltar la latencia de Hotstuff en un 33%. Sin embargo, es evidente que los protocolos de consenso basados en líderes no pueden aprovechar plenamente el potencial de rendimiento de Narwhal. A pesar de separar la propagación de datos del consenso, a medida que aumenta el rendimiento, el líder de Hotstuff/Jolteon sigue estando limitado.
Por lo tanto, decidimos desplegar Bullshark sobre Narwhal DAG, un protocolo de consenso con costo de comunicación cero. 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 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 difundir un vértice por ronda, y cada vértice hace referencia a 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 del DAG es que no es difusa: si dos nodos de validación tienen el mismo vértice v en su vista local del DAG, entonces tienen exactamente la misma historia causal de v.
Prefacio
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 los bordes representan votos.
Aunque la lógica de intersección de grupos en la estructura DAG es diferente, todos los protocolos de consenso existentes basados en Narwhal tienen la siguiente estructura:
Punto de anclaje reservado: cada ciertas rondas (, por ejemplo, en Bullshark, cada dos rondas ) hay un líder previamente determinado, y el punto culminante del líder se llama punto de anclaje;
Puntos de anclaje ordenados: los validadores deciden de manera independiente pero determinista cuáles anclajes ordenar y cuáles saltar;
Historia causal ordenada: los validadores procesan uno a uno la lista de anclajes ordenados, y para cada anclaje, ordenan todos los vértices desordenados anteriores en su historia causal a través de algunas reglas deterministas.
La clave para cumplir con 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 están de acuerdo con 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 Bullshark, la versión sincronizada, tiene mejor latencia que la versión asincrónica, está lejos de ser la óptima.
Pregunta 1: latencia media de bloques. En Bullshark, cada ronda par tiene un ancla, y los vértices de cada ronda impar se interpretan como votos. En situaciones comunes, se requieren dos rondas de DAG para ordenar los anclajes; sin embargo, los vértices en la historia causal del ancla requieren más rondas para esperar que el ancla sea ordenada. En situaciones comunes, los vértices en rondas impares requieren tres rondas, mientras que los vértices no ancla en rondas pares requieren cuatro rondas.
Pregunta 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 en una ronda no logra transmitir el ancla lo suficientemente rápido, no se puede ordenar el ancla (, por lo que se omite ). Por lo tanto, todos los vértices no ordenados en las primeras rondas deben esperar a que se ordene el siguiente ancla. 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 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íderes de costo cero en el DAG, lo que hace que la selección se incline hacia líderes rápidos.
Desafío
En el contexto del protocolo DAG, la 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 los futuros líderes en función del rendimiento pasado de los validadores en la idea de ancla en Bullshark (. Aunque las discrepancias en la identidad del líder no violan la seguridad de estos protocolos, en Bullshark, puede dar lugar a ordenaciones completamente diferentes, lo que plantea el núcleo del problema, es decir, que seleccionar de manera dinámica y determinista el ancla de la ronda es esencial para resolver el consenso, y los validadores necesitan llegar a un acuerdo sobre la historia ordenada para elegir futuros anclas.
Como evidencia de la dificultad del problema, notamos que la implementación de Bullshark, incluida la que actualmente se utiliza en el entorno de producción, no admite estas características.
Protocolo
A pesar de los desafíos mencionados, la solución se encuentra escondida en la simplicidad.
En Shoal, confiamos en la capacidad de ejecutar cálculos locales sobre DAG y logramos 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 con el primer punto de anclaje ordenado, Shoal combina secuencialmente múltiples instancias de Bullshark para procesarlas en línea, 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 de los líderes.
![Explicación detallada del marco Shoal: ¿Cómo Soltar la latencia de Bullshark en Aptos?])https://img-cdn.gateio.im/webp-social/moments-0b0928cb6240e994c1514c75e080a4b2.webp(
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á predefinida por el mapeo F. Cada instancia solicita 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 punto de anclaje ordenado, como en la ronda r. Todos los validadores estuvieron de acuerdo con 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 lanzó una nueva instancia de Bullshark en la ronda r+1.
En el mejor de los casos, esto permite a Shoal pedir un ancla en cada ronda. Los puntos de anclaje de la primera ronda se ordenan 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, y luego, otra nueva instancia pide un punto de anclaje en la tercera ronda, y así continúa el proceso.
![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 la ordenación de Bullshark, al omitir los puntos de anclaje, la latencia aumentará. En este caso, la técnica de canalización es inútil, ya que no se puede iniciar una nueva instancia antes de que se ordenen los puntos de anclaje de la instancia anterior. Shoal asegura que en el futuro sea menos probable que se elijan los líderes correspondientes para manejar los puntos de anclaje perdidos, asignando un puntaje a cada nodo de validación según la historia de actividad reciente de cada nodo de validación mediante el uso de un mecanismo de reputación. Los validadores que respondan y participen 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 estar caídos, lentos o actuar mal.
Su concepto es recalcular de manera determinista el mapeo predefinido F de cada ronda al líder en cada actualización de 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 alcanzar un consenso sobre las puntuaciones, logrando así un acuerdo en la historia utilizada para derivar las puntuaciones.
En Shoal, la cadena de bloques y la reputación del líder pueden combinarse de forma natural, ya que ambas utilizan la misma tecnología central, es decir, 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 Soltar la latencia de Bullshark en Aptos?])https://img-cdn.gateio.im/webp-social/moments-9f789cb669f6fcc244ea7ff7648e48b4.webp(
No hay más tiempo de espera
El tiempo de espera juega un papel crucial en todas las implementaciones BFT determinísticas basadas en líder. 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 requiere ajustes dinámicos, ya que depende en gran medida del entorno ) red (. Antes de pasar al siguiente líder, el protocolo pagará una penalización completa por la latencia de 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 saltarse a un buen líder. Por ejemplo, observamos que, en condiciones de alta carga, Jolteon/