Marco Shoal: Innovadora solución para reducir la latencia de Bullshark en Aptos
Aptos Labs ha logrado un avance significativo en el campo de DAG BFT, resolviendo dos problemas clave, reduciendo significativamente la latencia y eliminando por primera vez la necesidad de tiempo de espera en protocolos deterministas. En general, la latencia de Bullshark mejoró en un 40% en situaciones sin fallos y en un 80% en situaciones con fallos.
Shoal es un marco que mejora cualquier protocolo de consenso basado en Narwhal ( como DAG-Rider, Tusk, Bullshark ) mediante el procesamiento en paralelo y la reputación del líder. El procesamiento en paralelo 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íncrona para eliminar los tiempos de espera en todos los escenarios. Esto permite que Shoal ofrezca lo que llamamos "responsividad universal", que incluye la responsividad optimista que normalmente se requiere.
Nuestra tecnología es muy simple, esencialmente consiste en ejecutar múltiples instancias del protocolo subyacente en secuencia. Por lo tanto, al instanciar Bullshark, obtenemos un grupo de "tiburones" corriendo en una carrera de relevos.
Antecedentes y Motivación
En la búsqueda de un alto rendimiento en las redes de blockchain, la reducción de la complejidad de la comunicación ha sido un enfoque, pero este método 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 más de 100,000 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 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 propaguen datos simultáneamente, y el componente de consenso solo ordena una pequeña cantidad de metadatos. El documento de Narwhal reporta un rendimiento de 160,000 TPS.
Anteriormente presentamos Quorum Store, nuestra implementación de Narwhal que separa la propagación de datos del consenso, y 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 con cambios 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 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 sin costo de comunicación. Desafortunadamente, la estructura DAG que soporta el alto rendimiento de Bullshark conlleva un costo de latencia del 50% en comparación con Jolteon.
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, un validador debe primero obtener n-f vértices de 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 verificación tienen el mismo vértice v en su vista local de DAG, entonces tienen la misma historia causal de v.
Orden general
Se puede alcanzar 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: cada pocas rondas (, como en Bullshark, habrá un líder predeterminado, cuyo vértice 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 una lista de puntos de anclaje ordenados uno tras otro, y para cada punto de anclaje, ordenan todos los vértices desordenados anteriores en su historia causal mediante algunas reglas deterministas.
La clave para garantizar la seguridad es asegurar que en el paso )2(, todas las listas de puntos de anclaje ordenados creadas por nodos de verificación honestos compartan el mismo prefijo. En Shoal, hacemos las siguientes observaciones sobre todos los protocolos anteriores:
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 más práctica de Bullshark tiene una mejor latencia que la versión asíncrona, sigue estando lejos de ser óptima.
Pregunta 1: Latencia promedio de bloques. En Bullshark, cada ronda par tiene un ancla, y cada vértice de la ronda impar se interpreta como un voto. En casos comunes, se requieren 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 los anclajes se ordenen. En casos comunes, los vértices en la ronda impar necesitan tres rondas, mientras que los vértices no ancla en la ronda par 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 en una ronda no puede transmitir puntos de anclaje lo suficientemente rápido, no se pueden ordenar los puntos de anclaje ), por lo que se omiten (. Por lo tanto, todos los vértices no ordenados en las rondas anteriores deben esperar a que el siguiente punto de anclaje sea ordenado. Esto puede reducir significativamente el rendimiento de la red de replicación geográfica, especialmente porque Bullshark utiliza un tiempo de espera para esperar al 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-b7ed8888da112bae8d34c0fdb338b138.webp(
Marco Shoal
Shoal ha mejorado Bullshark) o cualquier otro protocolo BFT basado en Narwhal( mediante el procesamiento en línea, permitiendo que haya un ancla en cada ronda y reduciendo la latencia de todos los vértices no anclados en el DAG a tres rondas. Shoal también ha introducido un mecanismo de reputación del líder 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, el procesamiento en paralelo y la reputación de los líderes se consideran problemas difíciles, por las siguientes razones:
Los intentos anteriores de la línea de producción de modificar la lógica central de Bullshark parecían, en esencia, imposibles.
La reputación de los líderes se introduce en DiemBFT y se formaliza en Carousel, y se basa en la selección dinámica de futuros líderes según el rendimiento pasado de los validadores, la idea de los puntos de anclaje en )Bullshark. Aunque las discrepancias en la identidad del líder no violan la seguridad de estos protocolos, en Bullshark, pueden llevar a un orden completamente diferente, lo que plantea el núcleo del problema, es decir, que la selección dinámica y determinista de los anclajes de la rueda es necesaria para resolver el consenso, y los validadores necesitan llegar a un acuerdo sobre la historia ordenada para seleccionar los futuros anclajes.
Como evidencia de la dificultad del problema, notamos que la implementación de Bullshark, incluida la que actualmente está en el entorno de producción, no soporta estas características.
Protocolo
A pesar de los desafíos mencionados, la solución se oculta en la simplicidad.
En Shoal, confiamos en la capacidad de realizar cálculos locales en el DAG y logramos la habilidad de almacenar y reinterpretar la información de las rondas anteriores. Con la percepción central de que todos los validadores coinciden en el primer punto de anclaje ordenado, Shoal combina secuencialmente múltiples instancias de Bullshark para procesarlas en canalización, 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.
( procesamiento en línea
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 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 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 que Shoal ordene un ancla en cada ronda. El punto de anclaje de la primera ronda se ordena por 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 ordena el punto de anclaje en la tercera ronda, y así 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 periodo de ordenamiento de Bullshark, al omitir puntos de anclaje, la latencia aumentará. En este caso, la técnica de procesamiento en línea es impotente, ya que no se puede iniciar una nueva instancia antes del punto de anclaje de la instancia anterior. Shoal asegura que es poco probable que se elija el líder correspondiente para manejar los puntos de anclaje perdidos en el futuro, asignando una puntuación a cada nodo de validación según el historial de actividad reciente de cada nodo de validación mediante un mecanismo de reputación. Los validadores que respondan y participen en el protocolo recibirán altas puntuaciones; de lo contrario, se asignarán bajas puntuaciones a los nodos de validación, ya que podrían estar en fallo, ser lentos o actuar de manera malintencionada.
Su concepto es recalcular de manera determinista el mapeo predefinido F desde la ronda hasta el líder cada vez que se actualiza la puntuación, favoreciendo a los líderes con puntuaciones más altas. Para que los validadores lleguen a un consenso sobre el nuevo mapeo, deben llegar a un consenso sobre la puntuación, logrando así un acuerdo sobre la historia utilizada para derivar la puntuación.
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, 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, basado en la historia causal de los puntos de anclaje ordenados en la ronda r. Luego, los nodos de validación comienzan a ejecutar una nueva instancia de Bullshark utilizando la función de selección de puntos de anclaje actualizada F' a partir de la ronda r+1.
![Explicación detallada del marco Shoal: ¿Cómo reducir la latencia de Bullshark en Aptos?]###https://img-cdn.gateio.im/webp-social/moments-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 deben ser gestionados y observados, lo que incrementa la complejidad del proceso de depuración y requiere más técnicas de observabilidad.
El tiempo de espera también aumentará significativamente la latencia, ya que es muy importante configurarlos adecuadamente y a menudo requieren ajustes dinámicos, ya que dependen en gran medida del entorno ### red (. Antes de pasar al siguiente líder, el protocolo penaliza al líder fallido con la penalización completa por el tiempo de espera. 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, observamos que, en condiciones de alta carga, los líderes en Jolteon/Hotstuff estaban abrumados y el tiempo de espera ya había expirado antes de que pudieran impulsar el progreso.
Desafortunadamente, los protocolos de liderazgo ) como Hotstuff y Jolteon### esencialmente requieren latencia, para asegurar que cada vez que el líder falle.
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.
13 me gusta
Recompensa
13
6
Republicar
Compartir
Comentar
0/400
SandwichDetector
· hace8h
El aumento de rendimiento es realmente alcista, un 80% de mejora es increíble.
Ver originalesResponder0
NFTRegretful
· hace8h
Parece estar bien, solo que la velocidad no es lo suficientemente rápida.
Ver originalesResponder0
BearMarketSurvivor
· hace8h
latencia Soltar 80% esto es una verdadera fortaleza en el campo de batalla, espero el desempeño en la práctica
Ver originalesResponder0
CoinBasedThinking
· hace8h
Proyecto confiable, actualización técnica, espero que no sea un fiasco.
Ver originalesResponder0
MeaninglessGwei
· hace8h
¿La latencia disminuyó un 80%? Aptos ahora es alcista.
El marco Shoal mejora la eficiencia de consenso de Aptos, Bullshark Soltar la latencia en un 80%
Marco Shoal: Innovadora solución para reducir la latencia de Bullshark en Aptos
Aptos Labs ha logrado un avance significativo en el campo de DAG BFT, resolviendo dos problemas clave, reduciendo significativamente la latencia y eliminando por primera vez la necesidad de tiempo de espera en protocolos deterministas. En general, la latencia de Bullshark mejoró en un 40% en situaciones sin fallos y en un 80% en situaciones con fallos.
Shoal es un marco que mejora cualquier protocolo de consenso basado en Narwhal ( como DAG-Rider, Tusk, Bullshark ) mediante el procesamiento en paralelo y la reputación del líder. El procesamiento en paralelo 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íncrona para eliminar los tiempos de espera en todos los escenarios. Esto permite que Shoal ofrezca lo que llamamos "responsividad universal", que incluye la responsividad optimista que normalmente se requiere.
Nuestra tecnología es muy simple, esencialmente consiste en ejecutar múltiples instancias del protocolo subyacente en secuencia. Por lo tanto, al instanciar Bullshark, obtenemos un grupo de "tiburones" corriendo en una carrera de relevos.
Antecedentes y Motivación
En la búsqueda de un alto rendimiento en las redes de blockchain, la reducción de la complejidad de la comunicación ha sido un enfoque, pero este método 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 más de 100,000 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 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 propaguen datos simultáneamente, y el componente de consenso solo ordena una pequeña cantidad de metadatos. El documento de Narwhal reporta un rendimiento de 160,000 TPS.
Anteriormente presentamos Quorum Store, nuestra implementación de Narwhal que separa la propagación de datos del consenso, y 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 con cambios 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 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 sin costo de comunicación. Desafortunadamente, la estructura DAG que soporta el alto rendimiento de Bullshark conlleva un costo de latencia del 50% en comparación con Jolteon.
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, un validador debe primero obtener n-f vértices de 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 verificación tienen el mismo vértice v en su vista local de DAG, entonces tienen la misma historia causal de v.
Orden general
Se puede alcanzar 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: cada pocas rondas (, como en Bullshark, habrá un líder predeterminado, cuyo vértice 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 una lista de puntos de anclaje ordenados uno tras otro, y para cada punto de anclaje, ordenan todos los vértices desordenados anteriores en su historia causal mediante algunas reglas deterministas.
La clave para garantizar la seguridad es asegurar que en el paso )2(, todas las listas de puntos de anclaje ordenados creadas por nodos de verificación honestos compartan el mismo prefijo. En Shoal, hacemos las siguientes observaciones sobre todos los protocolos anteriores:
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 más práctica de Bullshark tiene una mejor latencia que la versión asíncrona, sigue estando lejos de ser óptima.
Pregunta 1: Latencia promedio de bloques. En Bullshark, cada ronda par tiene un ancla, y cada vértice de la ronda impar se interpreta como un voto. En casos comunes, se requieren 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 los anclajes se ordenen. En casos comunes, los vértices en la ronda impar necesitan tres rondas, mientras que los vértices no ancla en la ronda par 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 en una ronda no puede transmitir puntos de anclaje lo suficientemente rápido, no se pueden ordenar los puntos de anclaje ), por lo que se omiten (. Por lo tanto, todos los vértices no ordenados en las rondas anteriores deben esperar a que el siguiente punto de anclaje sea ordenado. Esto puede reducir significativamente el rendimiento de la red de replicación geográfica, especialmente porque Bullshark utiliza un tiempo de espera para esperar al 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-b7ed8888da112bae8d34c0fdb338b138.webp(
Marco Shoal
Shoal ha mejorado Bullshark) o cualquier otro protocolo BFT basado en Narwhal( mediante el procesamiento en línea, permitiendo que haya un ancla en cada ronda y reduciendo la latencia de todos los vértices no anclados en el DAG a tres rondas. Shoal también ha introducido un mecanismo de reputación del líder 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, el procesamiento en paralelo y la reputación de los líderes se consideran problemas difíciles, por las siguientes razones:
Los intentos anteriores de la línea de producción de modificar la lógica central de Bullshark parecían, en esencia, imposibles.
La reputación de los líderes se introduce en DiemBFT y se formaliza en Carousel, y se basa en la selección dinámica de futuros líderes según el rendimiento pasado de los validadores, la idea de los puntos de anclaje en )Bullshark. Aunque las discrepancias en la identidad del líder no violan la seguridad de estos protocolos, en Bullshark, pueden llevar a un orden completamente diferente, lo que plantea el núcleo del problema, es decir, que la selección dinámica y determinista de los anclajes de la rueda es necesaria para resolver el consenso, y los validadores necesitan llegar a un acuerdo sobre la historia ordenada para seleccionar los futuros anclajes.
Como evidencia de la dificultad del problema, notamos que la implementación de Bullshark, incluida la que actualmente está en el entorno de producción, no soporta estas características.
Protocolo
A pesar de los desafíos mencionados, la solución se oculta en la simplicidad.
En Shoal, confiamos en la capacidad de realizar cálculos locales en el DAG y logramos la habilidad de almacenar y reinterpretar la información de las rondas anteriores. Con la percepción central de que todos los validadores coinciden en el primer punto de anclaje ordenado, Shoal combina secuencialmente múltiples instancias de Bullshark para procesarlas en canalización, 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.
( procesamiento en línea
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 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 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 que Shoal ordene un ancla en cada ronda. El punto de anclaje de la primera ronda se ordena por 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 ordena el punto de anclaje en la tercera ronda, y así 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 periodo de ordenamiento de Bullshark, al omitir puntos de anclaje, la latencia aumentará. En este caso, la técnica de procesamiento en línea es impotente, ya que no se puede iniciar una nueva instancia antes del punto de anclaje de la instancia anterior. Shoal asegura que es poco probable que se elija el líder correspondiente para manejar los puntos de anclaje perdidos en el futuro, asignando una puntuación a cada nodo de validación según el historial de actividad reciente de cada nodo de validación mediante un mecanismo de reputación. Los validadores que respondan y participen en el protocolo recibirán altas puntuaciones; de lo contrario, se asignarán bajas puntuaciones a los nodos de validación, ya que podrían estar en fallo, ser lentos o actuar de manera malintencionada.
Su concepto es recalcular de manera determinista el mapeo predefinido F desde la ronda hasta el líder cada vez que se actualiza la puntuación, favoreciendo a los líderes con puntuaciones más altas. Para que los validadores lleguen a un consenso sobre el nuevo mapeo, deben llegar a un consenso sobre la puntuación, logrando así un acuerdo sobre la historia utilizada para derivar la puntuación.
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, 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, basado en la historia causal de los puntos de anclaje ordenados en la ronda r. Luego, los nodos de validación comienzan a ejecutar una nueva instancia de Bullshark utilizando la función de selección de puntos de anclaje actualizada F' a partir de la ronda r+1.
![Explicación detallada del marco Shoal: ¿Cómo reducir la latencia de Bullshark en Aptos?]###https://img-cdn.gateio.im/webp-social/moments-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 deben ser gestionados y observados, lo que incrementa la complejidad del proceso de depuración y requiere más técnicas de observabilidad.
El tiempo de espera también aumentará significativamente la latencia, ya que es muy importante configurarlos adecuadamente y a menudo requieren ajustes dinámicos, ya que dependen en gran medida del entorno ### red (. Antes de pasar al siguiente líder, el protocolo penaliza al líder fallido con la penalización completa por el tiempo de espera. 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, observamos que, en condiciones de alta carga, los líderes en Jolteon/Hotstuff estaban abrumados y el tiempo de espera ya había expirado antes de que pudieran impulsar el progreso.
Desafortunadamente, los protocolos de liderazgo ) como Hotstuff y Jolteon### esencialmente requieren latencia, para asegurar que cada vez que el líder falle.