Optimización del consenso DAG: Cómo Soltar la latencia de Bullshark en Aptos usando el marco Shoal
Aptos Labs ha resuelto recientemente dos importantes problemas abiertos en DAG BFT, reduciendo significativamente la latencia y eliminando por primera vez la necesidad de tiempos de espera en protocolos asíncronos deterministas. En general, el marco Shoal mejoró la latencia de Bullshark en un 40% en situaciones sin fallos y en un 80% en situaciones con fallos.
Shoal es un marco que mejora el protocolo de consenso basado en Narwhal ( a través de la tubería y la reputación del líder, como DAG-Rider, Tusk, Bullshark ). La tubería reduce la latencia del ordenamiento del DAG al introducir un punto de anclaje en cada ronda, mientras que la reputación del líder mejora aún más la 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 a Shoal aprovechar la construcción de DAG asíncrona para eliminar los tiempos de espera en todos los escenarios. Esto permite que Shoal ofrezca una capacidad de respuesta universal, que incluye la capacidad de respuesta optimista que normalmente se requiere.
La tecnología de Shoal es relativamente simple, involucrando múltiples instancias de protocolos subyacentes que se ejecutan en orden. Al instanciar con Bullshark, obtenemos un grupo de "tiburones" que están participando en una carrera de relevos.
Motivación
Al buscar un alto rendimiento en redes de 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, Hotstuff, implementado en las primeras versiones de Diem, solo logró 3500 TPS, muy por debajo del objetivo de 100k+ TPS.
Recientemente, el 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 se puede beneficiar de la paralelización. El sistema Narwhal separa la propagación de datos de la lógica central de consenso, proponiendo una arquitectura en la que todos los validadores propagan datos al mismo tiempo, mientras que el componente de consenso solo ordena una pequeña cantidad de metadatos. El documento de Narwhal reportó un rendimiento de 160,000 TPS.
En artículos anteriores, presentamos Quorum Store. Nuestra implementación de Narwhal separa la propagación de datos del consenso, así como cómo usarlo 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 los 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 throughput de Narwhal. A pesar de separar la propagación de datos del consenso, a medida que el throughput aumenta, los líderes de Hotstuff/Jolteon siguen estando limitados.
Por lo tanto, decidimos implementar Bullshark sobre el DAG de Narwhal, un protocolo de consenso sin costo de comunicación. Desafortunadamente, en comparación con Jolteon, la estructura DAG que soporta el alto rendimiento de Bullshark conlleva un costo de latencia del 50%.
Este artículo presenta cómo Shoal reduce significativamente la latencia de Bullshark.
Fondo 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 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 del DAG es la no ambigüedad: si dos nodos de validación tienen el mismo vértice v en la vista local del DAG, entonces tienen la misma historia causal de v.
Orden total
Se puede llegar a un consenso total sobre todos los vértices en el DAG sin costos adicionales 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 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 programado: cada ciertas rondas hay un líder predefinido, cuyo vértice se llama punto de anclaje.
Puntos de anclaje de ordenamiento: los validadores deciden de manera independiente pero determinista qué puntos de anclaje ordenar y cuáles omitir.
Ordenar la historia causal: los validadores procesan uno por uno la lista de anclajes ordenados, clasificando todos los vértices desordenados anteriores en la historia causal de cada anclaje.
La clave para satisfacer la seguridad es asegurar que en el paso (2), todas las listas de anclajes ordenadas creadas por los nodos de validación honestos compartan el mismo prefijo. En Shoal, hacemos las siguientes observaciones sobre todos estos protocolos:
Todos los validadores acuerdan el primer punto de anclaje ordenado.
Bullshark latencia
La latencia de Bullshark depende del número de rondas entre los puntos de anclaje ordenados en el DAG. Aunque la parte más práctica de Bullshark en la versión sincronizada tiene una mejor latencia que la versión asincrónica, todavía está lejos de ser óptima.
Pregunta 1: latencia promedio de bloques. En Bullshark, cada ronda par tiene un ancla, y el vértice de cada 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 del ancla requieren más rondas para esperar que los anclajes sean ordenados. En general, los vértices en rondas impares requieren tres rondas, mientras que los vértices no anclados en rondas pares requieren cuatro rondas.
Pregunta 2: latencia en la situación de falla. Si el líder de una ronda no logra transmitir lo suficientemente rápido el ancla, no se puede ordenar el ancla ( y, por lo tanto, se omite ). Todos los vértices no ordenados de las rondas anteriores deben esperar a que el siguiente ancla sea ordenado. Esto puede Soltar significativamente el rendimiento de la red de replicación geográfica, especialmente porque Bullshark utiliza un tiempo de espera para esperar al líder.
Marco de Shoal
Shoal ha mejorado Bullshark( o cualquier otro protocolo BFT basado en Narwhal) a través de una línea de producción, 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 de líderes sin costo 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 reputación de la línea de producción y del líder se considera un problema difícil, por las siguientes razones:
Los intentos anteriores de la línea de producción de modificar la lógica central de Bullshark parecen ser, en esencia, imposibles.
La reputación del líder se introduce en DiemBFT y se formaliza en Carousel, seleccionando dinámicamente a los futuros líderes según el rendimiento pasado de los validadores en la idea del anclaje en (Bullshark. Aunque la discrepancia en la identidad del líder no viola la seguridad de estos protocolos, puede llevar a un orden completamente diferente en Bullshark, lo que plantea el núcleo del problema: seleccionar de manera dinámica y determinista los anclajes de la ronda es necesario 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 implementación en el entorno de producción actual, no admite estas características.
Protocolo
A pesar de los desafíos anteriores, la solución se encuentra en la simplicidad.
En Shoal, dependemos de la capacidad de realizar cálculos locales sobre DAG y hemos logrado la capacidad de almacenar y reinterpretar la información de las rondas anteriores. Con la visión central de que todos los validadores acuerdan el primer anclaje ordenado, Shoal combina en secuencia múltiples instancias de Bullshark para su procesamiento en canal, haciendo que ) el primer anclaje ordenado sea el punto de cambio de las instancias, así como ( la historia causal de los anclajes se utilice para calcular la reputación del 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-46d37add0d9e81b2f295edf8eddd907f.webp(
Línea de flujo
V que asigna las rondas a los líderes. Shoal ejecuta instancias de Bullshark una tras otra, de modo que para cada instancia, el ancla es previamente determinado 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 funcionó 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 aceptar de manera confiable 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. El punto de anclaje de la primera ronda es ordenado por la primera instancia. Luego, Shoal comienza una nueva instancia en la segunda ronda, la cual 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, después 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 período de clasificación de Bullshark, la latencia aumenta al omitir los puntos de anclaje. En este caso, la tecnología de tuberías no puede ayudar, ya que no se puede iniciar una nueva instancia antes de que se clasifique el punto de anclaje de la instancia anterior. Shoal asegura que en el futuro sea menos probable que se elija al líder correspondiente para manejar los puntos de anclaje perdidos al asignar puntajes 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 responden y participan en el protocolo obtendrán puntajes altos; de lo contrario, se asignará un puntaje bajo a los nodos de validación, ya que pueden fallar, ser lentos o actuar maliciosamente.
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 puntajes más altos. Para que los validadores lleguen a un consenso sobre el nuevo mapeo, deben llegar a un acuerdo sobre la puntuación, logrando así un consenso en la historia utilizada para derivar la puntuación.
En Shoal, la reputación de la línea de producción y la de liderazgo pueden combinarse de manera natural, ya que ambas utilizan la misma tecnología central, es decir, reinterpretar el DAG después de alcanzar un consenso sobre el primer punto de anclaje ordenado.
De hecho, la única diferencia es que, después de la ordenación de los puntos de anclaje en la ronda r, los validadores solo necesitan calcular un nuevo mapeo F' a partir de la historia causal de los puntos de anclaje ordenados en la ronda r, comenzando desde la ronda r+1. Luego, los nodos de validación ejecutan 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 desempeña un papel crucial en todas las implementaciones BFT determinísticas 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.
El tiempo de espera también aumentará significativamente la latencia, ya que es muy importante configurarlos adecuadamente y generalmente necesitan 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 omitir buenos líderes. Por ejemplo, hemos observado que, en condiciones de alta carga, los líderes en Jolteon/Hotstuff están abrumados y el tiempo de espera ya ha expirado antes de que puedan impulsar el progreso.
Desafortunadamente, los protocolos basados en líderes ) como Hotstuff y Jolteon ( esencialmente requieren un tiempo de espera para asegurar que el protocolo avance cada vez que un líder falla. Sin un tiempo de espera, incluso un líder fallido podría detener el protocolo para siempre. Dado que durante el período asíncrono no se puede distinguir entre un líder fallido y un líder lento, el tiempo de espera podría llevar a los nodos de validación a ver cambios en todos los líderes sin actividad de consenso.
En Bullshark, el tiempo de espera se utiliza para la construcción de DAG, para asegurar que durante la sincronización el líder honesto agregue puntos de anclaje a
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.
11 me gusta
Recompensa
11
6
Republicar
Compartir
Comentar
0/400
GateUser-c799715c
· hace6h
¡El rendimiento ha mejorado bastante!
Ver originalesResponder0
AllInAlice
· hace9h
Es una persona dura 40% de reducción de latencia
Ver originalesResponder0
0xSherlock
· hace9h
latencia esta ola puede ser manejada un poco bien
Ver originalesResponder0
BrokenYield
· hace9h
meh, otra "optimización" que probablemente creará más riesgos sistémicos de los que soluciona... el dinero inteligente ya se está cubriendo contra esto
Ver originalesResponder0
FromMinerToFarmer
· hace9h
80% buena gente, realmente no está mal.
Ver originalesResponder0
BearMarketBard
· hace9h
El progreso es realmente grande, ¡esto ya está To the moon!
Optimización del marco Shoal para el consenso DAG, reduciendo significativamente la latencia de Bullshark en Aptos.
Optimización del consenso DAG: Cómo Soltar la latencia de Bullshark en Aptos usando el marco Shoal
Aptos Labs ha resuelto recientemente dos importantes problemas abiertos en DAG BFT, reduciendo significativamente la latencia y eliminando por primera vez la necesidad de tiempos de espera en protocolos asíncronos deterministas. En general, el marco Shoal mejoró la latencia de Bullshark en un 40% en situaciones sin fallos y en un 80% en situaciones con fallos.
Shoal es un marco que mejora el protocolo de consenso basado en Narwhal ( a través de la tubería y la reputación del líder, como DAG-Rider, Tusk, Bullshark ). La tubería reduce la latencia del ordenamiento del DAG al introducir un punto de anclaje en cada ronda, mientras que la reputación del líder mejora aún más la 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 a Shoal aprovechar la construcción de DAG asíncrona para eliminar los tiempos de espera en todos los escenarios. Esto permite que Shoal ofrezca una capacidad de respuesta universal, que incluye la capacidad de respuesta optimista que normalmente se requiere.
La tecnología de Shoal es relativamente simple, involucrando múltiples instancias de protocolos subyacentes que se ejecutan en orden. Al instanciar con Bullshark, obtenemos un grupo de "tiburones" que están participando en una carrera de relevos.
Motivación
Al buscar un alto rendimiento en redes de 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, Hotstuff, implementado en las primeras versiones de Diem, solo logró 3500 TPS, muy por debajo del objetivo de 100k+ TPS.
Recientemente, el 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 se puede beneficiar de la paralelización. El sistema Narwhal separa la propagación de datos de la lógica central de consenso, proponiendo una arquitectura en la que todos los validadores propagan datos al mismo tiempo, mientras que el componente de consenso solo ordena una pequeña cantidad de metadatos. El documento de Narwhal reportó un rendimiento de 160,000 TPS.
En artículos anteriores, presentamos Quorum Store. Nuestra implementación de Narwhal separa la propagación de datos del consenso, así como cómo usarlo 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 los 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 throughput de Narwhal. A pesar de separar la propagación de datos del consenso, a medida que el throughput aumenta, los líderes de Hotstuff/Jolteon siguen estando limitados.
Por lo tanto, decidimos implementar Bullshark sobre el DAG de Narwhal, un protocolo de consenso sin costo de comunicación. Desafortunadamente, en comparación con Jolteon, la estructura DAG que soporta el alto rendimiento de Bullshark conlleva un costo de latencia del 50%.
Este artículo presenta cómo Shoal reduce significativamente la latencia de Bullshark.
Fondo 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 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 del DAG es la no ambigüedad: si dos nodos de validación tienen el mismo vértice v en la vista local del DAG, entonces tienen la misma historia causal de v.
Orden total
Se puede llegar a un consenso total sobre todos los vértices en el DAG sin costos adicionales 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 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 programado: cada ciertas rondas hay un líder predefinido, cuyo vértice se llama punto de anclaje.
Puntos de anclaje de ordenamiento: los validadores deciden de manera independiente pero determinista qué puntos de anclaje ordenar y cuáles omitir.
Ordenar la historia causal: los validadores procesan uno por uno la lista de anclajes ordenados, clasificando todos los vértices desordenados anteriores en la historia causal de cada anclaje.
La clave para satisfacer la seguridad es asegurar que en el paso (2), todas las listas de anclajes ordenadas creadas por los nodos de validación honestos compartan el mismo prefijo. En Shoal, hacemos las siguientes observaciones sobre todos estos protocolos:
Todos los validadores acuerdan el primer punto de anclaje ordenado.
Bullshark latencia
La latencia de Bullshark depende del número de rondas entre los puntos de anclaje ordenados en el DAG. Aunque la parte más práctica de Bullshark en la versión sincronizada tiene una mejor latencia que la versión asincrónica, todavía está lejos de ser óptima.
Pregunta 1: latencia promedio de bloques. En Bullshark, cada ronda par tiene un ancla, y el vértice de cada 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 del ancla requieren más rondas para esperar que los anclajes sean ordenados. En general, los vértices en rondas impares requieren tres rondas, mientras que los vértices no anclados en rondas pares requieren cuatro rondas.
Pregunta 2: latencia en la situación de falla. Si el líder de una ronda no logra transmitir lo suficientemente rápido el ancla, no se puede ordenar el ancla ( y, por lo tanto, se omite ). Todos los vértices no ordenados de las rondas anteriores deben esperar a que el siguiente ancla sea ordenado. Esto puede Soltar significativamente el rendimiento de la red de replicación geográfica, especialmente porque Bullshark utiliza un tiempo de espera para esperar al líder.
Marco de Shoal
Shoal ha mejorado Bullshark( o cualquier otro protocolo BFT basado en Narwhal) a través de una línea de producción, 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 de líderes sin costo 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 reputación de la línea de producción y del líder se considera un problema difícil, por las siguientes razones:
Los intentos anteriores de la línea de producción de modificar la lógica central de Bullshark parecen ser, en esencia, imposibles.
La reputación del líder se introduce en DiemBFT y se formaliza en Carousel, seleccionando dinámicamente a los futuros líderes según el rendimiento pasado de los validadores en la idea del anclaje en (Bullshark. Aunque la discrepancia en la identidad del líder no viola la seguridad de estos protocolos, puede llevar a un orden completamente diferente en Bullshark, lo que plantea el núcleo del problema: seleccionar de manera dinámica y determinista los anclajes de la ronda es necesario 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 implementación en el entorno de producción actual, no admite estas características.
Protocolo
A pesar de los desafíos anteriores, la solución se encuentra en la simplicidad.
En Shoal, dependemos de la capacidad de realizar cálculos locales sobre DAG y hemos logrado la capacidad de almacenar y reinterpretar la información de las rondas anteriores. Con la visión central de que todos los validadores acuerdan el primer anclaje ordenado, Shoal combina en secuencia múltiples instancias de Bullshark para su procesamiento en canal, haciendo que ) el primer anclaje ordenado sea el punto de cambio de las instancias, así como ( la historia causal de los anclajes se utilice para calcular la reputación del 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-46d37add0d9e81b2f295edf8eddd907f.webp(
Línea de flujo
V que asigna las rondas a los líderes. Shoal ejecuta instancias de Bullshark una tras otra, de modo que para cada instancia, el ancla es previamente determinado 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 funcionó 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 aceptar de manera confiable 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. El punto de anclaje de la primera ronda es ordenado por la primera instancia. Luego, Shoal comienza una nueva instancia en la segunda ronda, la cual 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, después 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 período de clasificación de Bullshark, la latencia aumenta al omitir los puntos de anclaje. En este caso, la tecnología de tuberías no puede ayudar, ya que no se puede iniciar una nueva instancia antes de que se clasifique el punto de anclaje de la instancia anterior. Shoal asegura que en el futuro sea menos probable que se elija al líder correspondiente para manejar los puntos de anclaje perdidos al asignar puntajes 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 responden y participan en el protocolo obtendrán puntajes altos; de lo contrario, se asignará un puntaje bajo a los nodos de validación, ya que pueden fallar, ser lentos o actuar maliciosamente.
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 puntajes más altos. Para que los validadores lleguen a un consenso sobre el nuevo mapeo, deben llegar a un acuerdo sobre la puntuación, logrando así un consenso en la historia utilizada para derivar la puntuación.
En Shoal, la reputación de la línea de producción y la de liderazgo pueden combinarse de manera natural, ya que ambas utilizan la misma tecnología central, es decir, reinterpretar el DAG después de alcanzar un consenso sobre el primer punto de anclaje ordenado.
De hecho, la única diferencia es que, después de la ordenación de los puntos de anclaje en la ronda r, los validadores solo necesitan calcular un nuevo mapeo F' a partir de la historia causal de los puntos de anclaje ordenados en la ronda r, comenzando desde la ronda r+1. Luego, los nodos de validación ejecutan 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 desempeña un papel crucial en todas las implementaciones BFT determinísticas 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.
El tiempo de espera también aumentará significativamente la latencia, ya que es muy importante configurarlos adecuadamente y generalmente necesitan 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 omitir buenos líderes. Por ejemplo, hemos observado que, en condiciones de alta carga, los líderes en Jolteon/Hotstuff están abrumados y el tiempo de espera ya ha expirado antes de que puedan impulsar el progreso.
Desafortunadamente, los protocolos basados en líderes ) como Hotstuff y Jolteon ( esencialmente requieren un tiempo de espera para asegurar que el protocolo avance cada vez que un líder falla. Sin un tiempo de espera, incluso un líder fallido podría detener el protocolo para siempre. Dado que durante el período asíncrono no se puede distinguir entre un líder fallido y un líder lento, el tiempo de espera podría llevar a los nodos de validación a ver cambios en todos los líderes sin actividad de consenso.
En Bullshark, el tiempo de espera se utiliza para la construcción de DAG, para asegurar que durante la sincronización el líder honesto agregue puntos de anclaje a