Marco Shoal: Soltar la latencia de Bullshark en Aptos con un nuevo esquema
Aptos Labs recientemente resolvió dos problemas abiertos importantes en DAG BFT, lo que redujo significativamente la latencia y eliminó por primera vez la necesidad de un tiempo de espera en un protocolo práctico determinista. 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 el protocolo de consenso basado en Narwhal ( a través del procesamiento en línea y el mecanismo de reputación del líder, como DAG-Rider, Tusk, Bullshark ). El procesamiento en línea reduce la latencia de ordenamiento de DAG al introducir puntos de anclaje en cada ronda, y el mecanismo de reputación del líder mejora aún más el problema de 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 una propiedad denominada "respuesta universal", que incluye la respuesta optimista que generalmente se requiere.
La tecnología de Shoal es bastante simple, implica ejecutar múltiples instancias del protocolo subyacente una tras otra en orden. Por lo tanto, cuando se instancia Bullshark, obtenemos un grupo de "tiburones" que participan en una carrera de relevos.
Fondo
Al buscar un alto rendimiento en la red blockchain, la gente ha estado enfocándose en Soltar la complejidad de la comunicación. Sin embargo, este enfoque no ha llevado a un aumento significativo en el rendimiento. Por ejemplo, el Hotstuff implementado en las primeras versiones de Diem solo logró 3500 TPS, muy por debajo de nuestro 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 los líderes, y puede beneficiarse de la paralelización. El sistema Narwhal separa la propagación de datos de la lógica de consenso central, proponiendo una arquitectura en la que todos los validadores propagan datos simultáneamente, mientras que el componente de consenso solo ordena una cantidad reducida de metadatos. El documento de Narwhal reporta un rendimiento de 160,000 TPS.
Nuestra implementación de Narwhal Quorum Store separa la propagación de datos del consenso, para escalar el actual protocolo de consenso Jolteon. Jolteon es un protocolo basado en líderes que combina la ruta rápida lineal de Tendermint y un cambio de vista al estilo PBFT, lo que puede Soltar la latencia de Hotstuff en un 33%. Sin embargo, los protocolos de consenso basados en líderes no pueden aprovechar completamente el potencial de rendimiento de Narwhal. A pesar de separar la propagación de datos del consenso, a medida que aumenta el rendimiento, el líder de Hotstuff/Jolteon sigue estando limitado.
Por lo tanto, decidimos desplegar Bullshark sobre Narwhal DAG, un protocolo de consenso sin costos de comunicación. Desafortunadamente, en comparación con Jolteon, la estructura DAG que soporta un 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 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 del DAG no es ambigua: 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.
Introducción
Se puede lograr consenso sobre el orden total de todos los vértices en el DAG sin costo adicional de comunicación. 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 habrá un líder previamente determinado, el vértice del líder se llama punto de anclaje.
Puntos de anclaje de ordenación: los validadores deciden de manera independiente pero determinista cuáles puntos de anclaje ordenar y cuáles omitir.
Historia causal ordenada: los validadores manejan uno a uno una lista de puntos de anclaje ordenados, y para cada punto de anclaje, ordenan todos los vértices previos desordenados en su historia causal mediante reglas determinísticas.
La clave para satisfacer la seguridad es asegurarse de que en el paso (2), todos los nodos de validación honestos creen una lista de anclajes ordenada, de modo 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 versión sincronizada más práctica de Bullshark tiene una mejor latencia que la versión asincrónica, sigue estando lejos de ser óptima.
Pregunta 1: latencia promedio de bloque. En Bullshark, cada ronda par tiene un punto de anclaje, y los vértices de cada ronda impar se interpretan como votos. 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 la ronda impar requieren tres rondas, mientras que los vértices no anclados en la ronda par requieren cuatro rondas.
Problema 2: latencia de casos de falla, el análisis de latencia anterior se aplica a situaciones sin falla. Por otro lado, si un líder de ronda no logra transmitir los anclajes lo suficientemente rápido, no se puede ordenar los anclajes (, por lo que se omiten ). Por lo tanto, todos los vértices no ordenados en las primeras rondas deben esperar a que se ordene el siguiente anclaje. Esto puede Soltar significativamente el rendimiento de la red de replicación geográfica, especialmente porque Bullshark utiliza tiempos de espera para esperar al líder.
Marco Shoal
Shoal ha mejorado el Bullshark( o cualquier otro protocolo BFT basado en Narwhal) a través del procesamiento en línea, 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 ha introducido 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, el procesamiento en pipeline y la reputación del líder se consideran problemas difíciles, por las siguientes razones:
El procesamiento de líneas de producción anterior intentó 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 anclar en Bullshark (. Aunque las discrepancias en la identidad del líder no violan la seguridad de estos protocolos, en Bullshark, puede llevar a un orden completamente diferente, lo que plantea el núcleo del problema, a saber, que seleccionar anclas rotativas de manera dinámica y determinista es necesario para resolver el consenso, y los validadores necesitan ponerse de acuerdo sobre el historial ordenado para seleccionar las anclas futuras.
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 admite estas características.
Protocolo
A pesar de los desafíos mencionados, la solución se encuentra en la simplicidad.
En Shoal, nos basamos en la capacidad de realizar cálculos locales sobre DAG y logramos guardar y reinterpretar la información de rondas anteriores. Con la percepción central de que todos los validadores acuerdan el primer ancla ordenada, Shoal combina secuencialmente múltiples instancias de Bullshark para procesarlas en canal, haciendo de ) el punto de cambio de las instancias, así como la historia causal del ancla ( utilizada 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(
Procesamiento en línea
V que asigna la ronda a los líderes. Shoal ejecuta instancias de Bullshark una tras otra, de modo que para cada instancia, el ancla está previamente determinado por el mapeo F. Cada instancia ordena un ancla, lo que desencadena el cambio a la siguiente instancia.
Inicialmente, Shoal inició 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 estuvieron de acuerdo con este ancla. Por lo tanto, todos los validadores pueden estar de acuerdo en reinterpretar el DAG a partir de la ronda r+1. Shoal simplemente inició 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 anclaje de la primera ronda se ordenan según la primera instancia. Luego, Shoal inicia una nueva instancia en la segunda ronda, que tiene un 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 luego el proceso continúa.
![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(
Reputación del líder
Durante el ordenamiento de Bullshark, al saltar puntos de anclaje, la latencia aumenta. En este caso, la técnica de procesamiento en línea es impotente, 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 elija al líder correspondiente para manejar los puntos de anclaje perdidos en el futuro, asignando una puntuación a cada nodo de validación según el historial de actividad reciente de cada nodo de validación a través de un mecanismo de reputación. Los validadores que responden y participan en el protocolo recibirán una alta puntuación; de lo contrario, se asignará una baja puntuación a los nodos de validación, ya que podrían colapsar, ser lentos o actuar de manera maliciosa.
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 al líder con puntajes más altos. Para que los validadores lleguen a un consenso sobre el nuevo mapeo, deben alcanzar un consenso sobre las puntuaciones, logrando así un acuerdo sobre la historia utilizada para derivar las puntuaciones.
En Shoal, el procesamiento en línea y la reputación del líder pueden combinarse de forma natural, ya que ambos utilizan la misma tecnología central, que es 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, los validadores solo necesitan calcular un nuevo mapeo F' a partir de la ronda r+1, basándose en la historia causal de los puntos de anclaje ordenados en la ronda r. Luego, los nodos de validación utilizan la función de selección de puntos de anclaje actualizada F' para ejecutar una nueva instancia de Bullshark a partir de la ronda r+1.
![Explicación detallada del marco Shoal: ¿Cómo 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 deterministas basadas en líderes. Sin embargo, la complejidad que introducen aumenta el número 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 se requiere un ajuste dinámico, ya que depende en gran medida del entorno ) red (. Antes de pasar al siguiente líder, el protocolo paga 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 están abrumados, y el tiempo de espera ya ha expirado antes de que puedan avanzar.
Desafortunadamente, el protocolo basado en líderes ) como Hotstuff y Jolteon ( requiere esencialmente latencia para garantizar que cada vez que el líder falle, se pueda asegurar.
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.
14 me gusta
Recompensa
14
9
Compartir
Comentar
0/400
ChainComedian
· hace13h
latencia ha bajado tanto que siento que se puede hacer algo grande
Ver originalesResponder0
YouMustMakeBigMoneyEvery
· 07-19 04:14
más allá so l
Ver originalesResponder0
YouMustMakeBigMoneyEvery
· 07-19 04:14
Firme HODL💎
Ver originalesResponder0
VirtualRichDream
· 07-19 03:33
latencia Soltar tanto aptos ha comenzado a funcionar
Ver originalesResponder0
FOMOSapien
· 07-19 03:33
Reducir la latencia es mejor que simplemente A al presidente.
Ver originalesResponder0
BearEatsAll
· 07-19 03:30
¿Aptos puede ser más rápido? alcista!
Ver originalesResponder0
PaperHandsCriminal
· 07-19 03:26
Quién sabe para qué sirve esta latencia Soltar, aún no pudo evitar que me tomaran por tonto.
Ver originalesResponder0
ApeShotFirst
· 07-19 03:23
Otra vez sube, si no muere la latencia, será deslistado.
Ver originalesResponder0
BlockchainFries
· 07-19 03:15
Viendo que la latencia ha bajado tanto, mejor comprar una pequeña posición.
El marco Shoal reduce significativamente la latencia del consenso Bullshark en Aptos.
Marco Shoal: Soltar la latencia de Bullshark en Aptos con un nuevo esquema
Aptos Labs recientemente resolvió dos problemas abiertos importantes en DAG BFT, lo que redujo significativamente la latencia y eliminó por primera vez la necesidad de un tiempo de espera en un protocolo práctico determinista. 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 el protocolo de consenso basado en Narwhal ( a través del procesamiento en línea y el mecanismo de reputación del líder, como DAG-Rider, Tusk, Bullshark ). El procesamiento en línea reduce la latencia de ordenamiento de DAG al introducir puntos de anclaje en cada ronda, y el mecanismo de reputación del líder mejora aún más el problema de 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 una propiedad denominada "respuesta universal", que incluye la respuesta optimista que generalmente se requiere.
La tecnología de Shoal es bastante simple, implica ejecutar múltiples instancias del protocolo subyacente una tras otra en orden. Por lo tanto, cuando se instancia Bullshark, obtenemos un grupo de "tiburones" que participan en una carrera de relevos.
Fondo
Al buscar un alto rendimiento en la red blockchain, la gente ha estado enfocándose en Soltar la complejidad de la comunicación. Sin embargo, este enfoque no ha llevado a un aumento significativo en el rendimiento. Por ejemplo, el Hotstuff implementado en las primeras versiones de Diem solo logró 3500 TPS, muy por debajo de nuestro 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 los líderes, y puede beneficiarse de la paralelización. El sistema Narwhal separa la propagación de datos de la lógica de consenso central, proponiendo una arquitectura en la que todos los validadores propagan datos simultáneamente, mientras que el componente de consenso solo ordena una cantidad reducida de metadatos. El documento de Narwhal reporta un rendimiento de 160,000 TPS.
Nuestra implementación de Narwhal Quorum Store separa la propagación de datos del consenso, para escalar el actual protocolo de consenso Jolteon. Jolteon es un protocolo basado en líderes que combina la ruta rápida lineal de Tendermint y un cambio de vista al estilo PBFT, lo que puede Soltar la latencia de Hotstuff en un 33%. Sin embargo, los protocolos de consenso basados en líderes no pueden aprovechar completamente el potencial de rendimiento de Narwhal. A pesar de separar la propagación de datos del consenso, a medida que aumenta el rendimiento, el líder de Hotstuff/Jolteon sigue estando limitado.
Por lo tanto, decidimos desplegar Bullshark sobre Narwhal DAG, un protocolo de consenso sin costos de comunicación. Desafortunadamente, en comparación con Jolteon, la estructura DAG que soporta un 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 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 del DAG no es ambigua: 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.
Introducción
Se puede lograr consenso sobre el orden total de todos los vértices en el DAG sin costo adicional de comunicación. 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 habrá un líder previamente determinado, el vértice del líder se llama punto de anclaje.
Puntos de anclaje de ordenación: los validadores deciden de manera independiente pero determinista cuáles puntos de anclaje ordenar y cuáles omitir.
Historia causal ordenada: los validadores manejan uno a uno una lista de puntos de anclaje ordenados, y para cada punto de anclaje, ordenan todos los vértices previos desordenados en su historia causal mediante reglas determinísticas.
La clave para satisfacer la seguridad es asegurarse de que en el paso (2), todos los nodos de validación honestos creen una lista de anclajes ordenada, de modo 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 versión sincronizada más práctica de Bullshark tiene una mejor latencia que la versión asincrónica, sigue estando lejos de ser óptima.
Pregunta 1: latencia promedio de bloque. En Bullshark, cada ronda par tiene un punto de anclaje, y los vértices de cada ronda impar se interpretan como votos. 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 la ronda impar requieren tres rondas, mientras que los vértices no anclados en la ronda par requieren cuatro rondas.
Problema 2: latencia de casos de falla, el análisis de latencia anterior se aplica a situaciones sin falla. Por otro lado, si un líder de ronda no logra transmitir los anclajes lo suficientemente rápido, no se puede ordenar los anclajes (, por lo que se omiten ). Por lo tanto, todos los vértices no ordenados en las primeras rondas deben esperar a que se ordene el siguiente anclaje. Esto puede Soltar significativamente el rendimiento de la red de replicación geográfica, especialmente porque Bullshark utiliza tiempos de espera para esperar al líder.
Marco Shoal
Shoal ha mejorado el Bullshark( o cualquier otro protocolo BFT basado en Narwhal) a través del procesamiento en línea, 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 ha introducido 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, el procesamiento en pipeline y la reputación del líder se consideran problemas difíciles, por las siguientes razones:
El procesamiento de líneas de producción anterior intentó 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 anclar en Bullshark (. Aunque las discrepancias en la identidad del líder no violan la seguridad de estos protocolos, en Bullshark, puede llevar a un orden completamente diferente, lo que plantea el núcleo del problema, a saber, que seleccionar anclas rotativas de manera dinámica y determinista es necesario para resolver el consenso, y los validadores necesitan ponerse de acuerdo sobre el historial ordenado para seleccionar las anclas futuras.
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 admite estas características.
Protocolo
A pesar de los desafíos mencionados, la solución se encuentra en la simplicidad.
En Shoal, nos basamos en la capacidad de realizar cálculos locales sobre DAG y logramos guardar y reinterpretar la información de rondas anteriores. Con la percepción central de que todos los validadores acuerdan el primer ancla ordenada, Shoal combina secuencialmente múltiples instancias de Bullshark para procesarlas en canal, haciendo de ) el punto de cambio de las instancias, así como la historia causal del ancla ( utilizada 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(
Procesamiento en línea
V que asigna la ronda a los líderes. Shoal ejecuta instancias de Bullshark una tras otra, de modo que para cada instancia, el ancla está previamente determinado por el mapeo F. Cada instancia ordena un ancla, lo que desencadena el cambio a la siguiente instancia.
Inicialmente, Shoal inició 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 estuvieron de acuerdo con este ancla. Por lo tanto, todos los validadores pueden estar de acuerdo en reinterpretar el DAG a partir de la ronda r+1. Shoal simplemente inició 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 anclaje de la primera ronda se ordenan según la primera instancia. Luego, Shoal inicia una nueva instancia en la segunda ronda, que tiene un 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 luego el proceso continúa.
![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(
Reputación del líder
Durante el ordenamiento de Bullshark, al saltar puntos de anclaje, la latencia aumenta. En este caso, la técnica de procesamiento en línea es impotente, 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 elija al líder correspondiente para manejar los puntos de anclaje perdidos en el futuro, asignando una puntuación a cada nodo de validación según el historial de actividad reciente de cada nodo de validación a través de un mecanismo de reputación. Los validadores que responden y participan en el protocolo recibirán una alta puntuación; de lo contrario, se asignará una baja puntuación a los nodos de validación, ya que podrían colapsar, ser lentos o actuar de manera maliciosa.
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 al líder con puntajes más altos. Para que los validadores lleguen a un consenso sobre el nuevo mapeo, deben alcanzar un consenso sobre las puntuaciones, logrando así un acuerdo sobre la historia utilizada para derivar las puntuaciones.
En Shoal, el procesamiento en línea y la reputación del líder pueden combinarse de forma natural, ya que ambos utilizan la misma tecnología central, que es 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, los validadores solo necesitan calcular un nuevo mapeo F' a partir de la ronda r+1, basándose en la historia causal de los puntos de anclaje ordenados en la ronda r. Luego, los nodos de validación utilizan la función de selección de puntos de anclaje actualizada F' para ejecutar una nueva instancia de Bullshark a partir de la ronda r+1.
![Explicación detallada del marco Shoal: ¿Cómo 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 deterministas basadas en líderes. Sin embargo, la complejidad que introducen aumenta el número 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 se requiere un ajuste dinámico, ya que depende en gran medida del entorno ) red (. Antes de pasar al siguiente líder, el protocolo paga 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 están abrumados, y el tiempo de espera ya ha expirado antes de que puedan avanzar.
Desafortunadamente, el protocolo basado en líderes ) como Hotstuff y Jolteon ( requiere esencialmente latencia para garantizar que cada vez que el líder falle, se pueda asegurar.