Marco Shoal: Cómo Soltar la latencia de Bullshark en Aptos
Aptos Labs resolvió dos importantes problemas abiertos en el DAG BFT, lo que redujo significativamente la latencia y eliminó por primera vez la necesidad de tiempos 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 situaciones de fallo.
Shoal es un marco que mejora cualquier protocolo de consenso basado en Narwhal (, como DAG-Rider, Tusk, Bullshark ), a través de una tubería y la reputación del líder. La tubería reduce la latencia de ordenamiento de DAG al introducir puntos de anclaje en cada ronda, y la 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 que Shoal utilice construcciones de DAG asíncronas para eliminar los tiempos de espera en todos los escenarios. Esto permite que Shoal proporcione propiedades de respuesta universal, que incluyen respuestas optimistas que normalmente se requieren.
Esta tecnología es muy simple, implica ejecutar múltiples instancias del protocolo subyacente en orden. Por lo tanto, al instanciar Bullshark, obtenemos un grupo de "tiburones" que están en una carrera de relevos.
Antecedentes
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 de la meta de 100k+ TPS.
El reciente avance proviene de la comprensión de que la propagación de datos es un 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 que todos los validadores propaguen datos simultáneamente, mientras que el componente de consenso solo ordena una pequeña cantidad de metadatos. El documento de Narwhal reportó una capacidad de 160,000 TPS.
El Quorum Store presentado anteriormente es la implementación de Narwhal, que separa la propagación de datos del consenso, utilizado para escalar el protocolo de consenso actual Jolteon. Jolteon es un protocolo basado en líderes, que combina la ruta rápida lineal de Tendermint y el cambio de vista al estilo PBFT, reduciendo 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.
Por lo tanto, se decidió implementar Bullshark sobre Narwhal DAG, que es un protocolo de consenso de cero 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.
Fondo 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 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 de las características clave de DAG es la no ambigüedad: si dos nodos de validación tienen el mismo vértice v en la vista local de DAG, entonces tienen exactamente la misma historia causal de v.
Orden total
Se puede alcanzar un consenso total sobre 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.
Todos los protocolos de consenso basados en Narwhal existentes tienen la siguiente estructura:
Punto de anclaje programado: cada ciertos ciclos hay un líder previamente determinado, y el vértice del líder se llama 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 uno tras otro una lista de puntos de anclaje ordenados, ordenando todos los vértices desordenados anteriores en la historia causal de cada punto de anclaje según reglas de determinación.
La clave para satisfacer la seguridad es asegurar que en el paso (2), todos los nodos de verificación honestos compartan la misma prefijo en la lista de puntos de anclaje ordenados que crean. Shoal hace las siguientes observaciones sobre todos estos protocolos:
Todos los validadores están de acuerdo en 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 algunas versiones de sincronización tienen una latencia mejor que las versiones asíncronas, todavía están lejos de ser las óptimas.
Pregunta 1: latencia promedio de bloques. En Bullshark, hay un ancla en cada ronda par, 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 el orden de los anclajes. Por lo general, los vértices de las rondas impares requieren tres rondas, y los vértices no anclados de las rondas pares requieren cuatro rondas.
Problema 2: latencia en casos de fallos. Si un líder en una ronda no logra transmitir lo suficientemente rápido el ancla, no se puede ordenar el ancla (, que se omite ). Todos los vértices no ordenados de las rondas anteriores deben esperar a que se ordene el siguiente ancla. Esto disminuye significativamente el rendimiento de la red de replicación geográfica, especialmente porque Bullshark utiliza un tiempo de espera para esperar al líder.
Marco Shoal
Shoal mejora Bullshark( o cualquier otro protocolo BFT basado en Narwhal) a través de una línea de producción, permitiendo que cada ronda tenga un ancla, reduciendo la latencia de todos los vértices no anclados en el DAG a tres rondas. Shoal también introduce un mecanismo de reputación de líder de costo cero en el DAG, favoreciendo la selección de líderes rápidos.
Desafío
En el contexto del protocolo DAG, la reputación de la cadena de bloques y del líder se considera un problema difícil, por las siguientes razones:
Los intentos anteriores de modificar la lógica central de Bullshark en la línea de producción parecen ser, en esencia, imposibles.
La reputación del líder se introduce en DiemBFT y se formaliza en Carousel, eligiendo dinámicamente a los futuros líderes según el rendimiento pasado de los validadores ( anclaje en Bullshark ). Aunque las discrepancias sobre la identidad del líder no violan la seguridad de estos protocolos, pueden resultar en un orden completamente diferente en Bullshark, lo que plantea la cuestión central: la elección dinámica y determinista de los anclajes de ronda es necesaria para resolver el consenso, y los validadores necesitan llegar a un acuerdo sobre la historia ordenada para seleccionar futuros anclajes.
Como evidencia de la dificultad del problema, la implementación de Bullshark ( no incluye características que actualmente no son compatibles en el entorno de producción.
Protocolo
Shoal se basa en la capacidad de realizar cálculos locales en DAG, logrando la capacidad de guardar y reinterpretar la información de rondas anteriores. Con el consenso de todos los validadores sobre la percepción del primer ancla ordenada, Shoal combina secuencialmente múltiples instancias de Bullshark para su procesamiento en línea, lo que hace que ) el primer ancla ordenada sea un punto de cambio de instancia, ( la historia causal del ancla se utiliza para calcular la reputación del líder.
) línea de producción
V que asigna rondas a líderes. Shoal ejecuta instancias de Bullshark una tras otra, donde el ancla de cada instancia está predefinido 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 de DAG y funcionó 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 seguros de que pueden reinterpretar el DAG desde la ronda r+1. Shoal simplemente inicia 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 primer punto de anclaje es ordenado por la primera instancia. Luego, Shoal inicia 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 un punto de anclaje en la tercera ronda, y el proceso continúa.
Reputación del líder
Cuando se omiten los puntos de anclaje durante el ordenamiento de Bullshark, la latencia aumenta. En este caso, la tubería es impotente, 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 es poco probable que se elija al líder correspondiente para manejar los puntos de anclaje perdidos, utilizando un mecanismo de reputación que asigna puntajes según el historial de actividad reciente de cada nodo de validación. Los validadores que responden y participan en el protocolo reciben puntuaciones altas; de lo contrario, se les asignan puntuaciones bajas, ya que podrían 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 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, la línea de producción y la reputación de liderazgo pueden combinarse de manera natural, ya que ambas utilizan la misma tecnología central, que consiste en reinterpretar el DAG después de llegar a un consenso sobre el primer ancla ordenada.
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 de 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.
sin tiempo de espera
El tiempo de espera juega un papel clave 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 de depuración y requiere más técnicas de observabilidad.
El tiempo de espera también aumentará significativamente la latencia, ya que es importante configurarlos correctamente, lo que generalmente requiere ajustes dinámicos y depende en gran medida del entorno ( red ). Antes de pasar al siguiente líder, el protocolo pagará una penalización completa por la latencia del tiempo de espera para los líderes con fallas. Por lo tanto, la configuración del tiempo de espera no puede ser demasiado conservadora, pero si es demasiado corta, el protocolo podría saltarse buenos líderes. Por ejemplo, observamos que bajo alta carga, los líderes en Jolteon/Hotstuff se vieron abrumados, y el tiempo de espera ya había expirado antes de impulsar el progreso.
Desafortunadamente, los protocolos basados en líderes ### como Hotstuff y Jolteon ( esencialmente requieren latencia, para asegurar que el protocolo avance cada vez que falle un líder. Sin latencia, incluso un líder caído podría detener el protocolo indefinidamente. Dado que durante el período asincrónico no se puede distinguir entre un líder fallido y un líder lento, la latencia podría llevar a que los nodos de validación cambien todos los líderes sin actividad de consenso.
En Bullshark, el tiempo de espera se utiliza para la construcción del DAG, para asegurar que durante la sincronización los líderes honestos agreguen puntos de anclaje al DAG lo suficientemente rápido para su ordenación.
Observamos que la construcción de DAG proporciona un "reloj" para estimar la velocidad de la red. En ausencia de pausas, siempre que n-f validadores honestos continúen agregando vértices al DAG, los turnos seguirán avanzando. Aunque Bullshark puede no ser capaz de ordenar a la velocidad de la red ) debido a problemas de liderazgo (, el DAG sigue creciendo a la velocidad de la red, a pesar de que algunos líderes tienen problemas o la red es asíncrona. Finalmente, cuando suficientes líderes sin fallos transmiten rápidamente los puntos de anclaje, toda la historia causal de los puntos de anclaje será ordenada.
En nuestra evaluación, se comparó si Bullshark tuvo latencia en las siguientes situaciones:
Líder rápido: al menos más rápido que otros validadores. Dos métodos ofrecen la misma latencia, ya que el ancla es ordenada y no utiliza tiempo de espera.
Líderes erróneos: Bullshark sin tiempo de espera proporciona mejor latencia, ya que los nodos de validación saltan inmediatamente su.
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.
10 me gusta
Recompensa
10
4
Republicar
Compartir
Comentar
0/400
HashRateHermit
· hace13h
¿Latencia mejorada en un 80%? ¡Qué alcista!
Ver originalesResponder0
SelfRugger
· hace13h
80% reducción de latencia, hasta el padre Ma grita alcista
Ver originalesResponder0
CommunitySlacker
· hace13h
alcista cerveza latencia optimizada en un 80%
Ver originalesResponder0
Hash_Bandit
· hace13h
maldita sea, esto es como cuando optimizamos la dificultad de la minería de btc en 2013... grandes ganancias de hashrate fr
Marco Shoal: Optimización de latencia Bullshark en Aptos
Marco Shoal: Cómo Soltar la latencia de Bullshark en Aptos
Aptos Labs resolvió dos importantes problemas abiertos en el DAG BFT, lo que redujo significativamente la latencia y eliminó por primera vez la necesidad de tiempos 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 situaciones de fallo.
Shoal es un marco que mejora cualquier protocolo de consenso basado en Narwhal (, como DAG-Rider, Tusk, Bullshark ), a través de una tubería y la reputación del líder. La tubería reduce la latencia de ordenamiento de DAG al introducir puntos de anclaje en cada ronda, y la 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 que Shoal utilice construcciones de DAG asíncronas para eliminar los tiempos de espera en todos los escenarios. Esto permite que Shoal proporcione propiedades de respuesta universal, que incluyen respuestas optimistas que normalmente se requieren.
Esta tecnología es muy simple, implica ejecutar múltiples instancias del protocolo subyacente en orden. Por lo tanto, al instanciar Bullshark, obtenemos un grupo de "tiburones" que están en una carrera de relevos.
Antecedentes
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 de la meta de 100k+ TPS.
El reciente avance proviene de la comprensión de que la propagación de datos es un 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 que todos los validadores propaguen datos simultáneamente, mientras que el componente de consenso solo ordena una pequeña cantidad de metadatos. El documento de Narwhal reportó una capacidad de 160,000 TPS.
El Quorum Store presentado anteriormente es la implementación de Narwhal, que separa la propagación de datos del consenso, utilizado para escalar el protocolo de consenso actual Jolteon. Jolteon es un protocolo basado en líderes, que combina la ruta rápida lineal de Tendermint y el cambio de vista al estilo PBFT, reduciendo 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.
Por lo tanto, se decidió implementar Bullshark sobre Narwhal DAG, que es un protocolo de consenso de cero 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.
Fondo 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 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 de las características clave de DAG es la no ambigüedad: si dos nodos de validación tienen el mismo vértice v en la vista local de DAG, entonces tienen exactamente la misma historia causal de v.
Orden total
Se puede alcanzar un consenso total sobre 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.
Todos los protocolos de consenso basados en Narwhal existentes tienen la siguiente estructura:
Punto de anclaje programado: cada ciertos ciclos hay un líder previamente determinado, y el vértice del líder se llama 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 uno tras otro una lista de puntos de anclaje ordenados, ordenando todos los vértices desordenados anteriores en la historia causal de cada punto de anclaje según reglas de determinación.
La clave para satisfacer la seguridad es asegurar que en el paso (2), todos los nodos de verificación honestos compartan la misma prefijo en la lista de puntos de anclaje ordenados que crean. Shoal hace las siguientes observaciones sobre todos estos protocolos:
Todos los validadores están de acuerdo en 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 algunas versiones de sincronización tienen una latencia mejor que las versiones asíncronas, todavía están lejos de ser las óptimas.
Pregunta 1: latencia promedio de bloques. En Bullshark, hay un ancla en cada ronda par, 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 el orden de los anclajes. Por lo general, los vértices de las rondas impares requieren tres rondas, y los vértices no anclados de las rondas pares requieren cuatro rondas.
Problema 2: latencia en casos de fallos. Si un líder en una ronda no logra transmitir lo suficientemente rápido el ancla, no se puede ordenar el ancla (, que se omite ). Todos los vértices no ordenados de las rondas anteriores deben esperar a que se ordene el siguiente ancla. Esto disminuye significativamente el rendimiento de la red de replicación geográfica, especialmente porque Bullshark utiliza un tiempo de espera para esperar al líder.
Marco Shoal
Shoal mejora Bullshark( o cualquier otro protocolo BFT basado en Narwhal) a través de una línea de producción, permitiendo que cada ronda tenga un ancla, reduciendo la latencia de todos los vértices no anclados en el DAG a tres rondas. Shoal también introduce un mecanismo de reputación de líder de costo cero en el DAG, favoreciendo la selección de líderes rápidos.
Desafío
En el contexto del protocolo DAG, la reputación de la cadena de bloques y del líder se considera un problema difícil, por las siguientes razones:
Los intentos anteriores de modificar la lógica central de Bullshark en la línea de producción parecen ser, en esencia, imposibles.
La reputación del líder se introduce en DiemBFT y se formaliza en Carousel, eligiendo dinámicamente a los futuros líderes según el rendimiento pasado de los validadores ( anclaje en Bullshark ). Aunque las discrepancias sobre la identidad del líder no violan la seguridad de estos protocolos, pueden resultar en un orden completamente diferente en Bullshark, lo que plantea la cuestión central: la elección dinámica y determinista de los anclajes de ronda es necesaria para resolver el consenso, y los validadores necesitan llegar a un acuerdo sobre la historia ordenada para seleccionar futuros anclajes.
Como evidencia de la dificultad del problema, la implementación de Bullshark ( no incluye características que actualmente no son compatibles en el entorno de producción.
Protocolo
Shoal se basa en la capacidad de realizar cálculos locales en DAG, logrando la capacidad de guardar y reinterpretar la información de rondas anteriores. Con el consenso de todos los validadores sobre la percepción del primer ancla ordenada, Shoal combina secuencialmente múltiples instancias de Bullshark para su procesamiento en línea, lo que hace que ) el primer ancla ordenada sea un punto de cambio de instancia, ( la historia causal del ancla se utiliza para calcular la reputación del líder.
) línea de producción
V que asigna rondas a líderes. Shoal ejecuta instancias de Bullshark una tras otra, donde el ancla de cada instancia está predefinido 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 de DAG y funcionó 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 seguros de que pueden reinterpretar el DAG desde la ronda r+1. Shoal simplemente inicia 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 primer punto de anclaje es ordenado por la primera instancia. Luego, Shoal inicia 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 un punto de anclaje en la tercera ronda, y el proceso continúa.
Reputación del líder
Cuando se omiten los puntos de anclaje durante el ordenamiento de Bullshark, la latencia aumenta. En este caso, la tubería es impotente, 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 es poco probable que se elija al líder correspondiente para manejar los puntos de anclaje perdidos, utilizando un mecanismo de reputación que asigna puntajes según el historial de actividad reciente de cada nodo de validación. Los validadores que responden y participan en el protocolo reciben puntuaciones altas; de lo contrario, se les asignan puntuaciones bajas, ya que podrían 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 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, la línea de producción y la reputación de liderazgo pueden combinarse de manera natural, ya que ambas utilizan la misma tecnología central, que consiste en reinterpretar el DAG después de llegar a un consenso sobre el primer ancla ordenada.
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 de 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.
sin tiempo de espera
El tiempo de espera juega un papel clave 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 de depuración y requiere más técnicas de observabilidad.
El tiempo de espera también aumentará significativamente la latencia, ya que es importante configurarlos correctamente, lo que generalmente requiere ajustes dinámicos y depende en gran medida del entorno ( red ). Antes de pasar al siguiente líder, el protocolo pagará una penalización completa por la latencia del tiempo de espera para los líderes con fallas. Por lo tanto, la configuración del tiempo de espera no puede ser demasiado conservadora, pero si es demasiado corta, el protocolo podría saltarse buenos líderes. Por ejemplo, observamos que bajo alta carga, los líderes en Jolteon/Hotstuff se vieron abrumados, y el tiempo de espera ya había expirado antes de impulsar el progreso.
Desafortunadamente, los protocolos basados en líderes ### como Hotstuff y Jolteon ( esencialmente requieren latencia, para asegurar que el protocolo avance cada vez que falle un líder. Sin latencia, incluso un líder caído podría detener el protocolo indefinidamente. Dado que durante el período asincrónico no se puede distinguir entre un líder fallido y un líder lento, la latencia podría llevar a que los nodos de validación cambien todos los líderes sin actividad de consenso.
En Bullshark, el tiempo de espera se utiliza para la construcción del DAG, para asegurar que durante la sincronización los líderes honestos agreguen puntos de anclaje al DAG lo suficientemente rápido para su ordenación.
Observamos que la construcción de DAG proporciona un "reloj" para estimar la velocidad de la red. En ausencia de pausas, siempre que n-f validadores honestos continúen agregando vértices al DAG, los turnos seguirán avanzando. Aunque Bullshark puede no ser capaz de ordenar a la velocidad de la red ) debido a problemas de liderazgo (, el DAG sigue creciendo a la velocidad de la red, a pesar de que algunos líderes tienen problemas o la red es asíncrona. Finalmente, cuando suficientes líderes sin fallos transmiten rápidamente los puntos de anclaje, toda la historia causal de los puntos de anclaje será ordenada.
En nuestra evaluación, se comparó si Bullshark tuvo latencia en las siguientes situaciones:
Líder rápido: al menos más rápido que otros validadores. Dos métodos ofrecen la misma latencia, ya que el ancla es ordenada y no utiliza tiempo de espera.
Líderes erróneos: Bullshark sin tiempo de espera proporciona mejor latencia, ya que los nodos de validación saltan inmediatamente su.