Reducción de la latencia de Bullshark en Aptos: Explicación del marco Shoal
Aptos labs resolvió dos importantes problemas abiertos en DAG BFT, reduciendo significativamente la latencia y eliminando por primera vez la necesidad de pausas en los protocolos prácticos deterministas. En general, mejoró la latencia de Bullshark en un 40% en condiciones sin fallos y en un 80% en caso de fallos.
El marco Shoal mejora el protocolo de consenso basado en Narwhal ( a través de mecanismos de canalización y reputación de líderes, como DAG-Rider, Tusk, Bullshark ). La canalización introduce un punto de anclaje en cada ronda para reducir la latencia de ordenamiento de DAG, y la reputación del líder asegura que los puntos de anclaje estén asociados con los nodos de validación más rápidos, mejorando aún más la latencia. 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, logrando así propiedades de respuesta general.
La tecnología de Shoal es muy simple, ejecuta múltiples instancias del protocolo subyacente en orden. Cuando se instancia con Bullshark, es como un grupo de "tiburones" que están en una carrera de relevos.
Fondo
Al buscar un alto rendimiento en redes de blockchain, las personas siempre se han centrado en reducir la complejidad de la comunicación, pero esto no ha llevado a un aumento significativo en el rendimiento. Por ejemplo, el Hotstuff implementado en el temprano Diem solo alcanzó 3500 TPS, muy por debajo del objetivo de 100k+ TPS.
Recientemente, la ruptura 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, lo que puede beneficiarse de la paralelización. El sistema Narwhal separa la propagación de datos de la lógica de consenso central, todos los validadores propagan datos al mismo tiempo, y el componente de consenso solo ordena una pequeña cantidad de metadatos. El documento de Narwhal reportó una capacidad de 160,000 TPS.
Aptos presentó anteriormente Quorum Store, que es la implementación de Narwhal, separando la propagación de datos de la consenso, y se utiliza para escalar el protocolo de consenso actual Jolteon. Jolteon combina el camino rápido 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 plenamente el potencial de rendimiento de Narwhal.
Por lo tanto, Aptos decidió implementar Bullshark sobre el DAG de Narwhal, un protocolo de consenso sin costos de comunicación. Desafortunadamente, 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.
Contexto de DAG-BFT
Cada vértice en el DAG de Narwhal está relacionado con un número de ronda. Al entrar en la ronda r, un validador debe obtener n-f vértices de la ronda r-1. Cada validador puede transmitir un vértice por ronda, y cada vértice debe hacer referencia al menos a 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.
Una propiedad clave de DAG es que no es difusa: si dos nodos de validación tienen el mismo vértice v en su vista local de DAG, entonces tienen exactamente la misma historia causal de v.
Orden de secuencia
Se puede alcanzar un consenso sobre el orden total de todos los vértices en el DAG sin costos adicionales de comunicación. 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 grupal en la estructura DAG es diferente, todos los protocolos de consenso basados en Narwhal tienen la siguiente estructura:
Punto de anclaje: cada pocas rondas hay un líder preestablecido, cuyo vértice se llama punto de anclaje.
Puntos de anclaje de orden: los validadores deciden de manera independiente pero determinista qué puntos de anclaje ordenar y cuáles omitir.
Historia causal ordenada: los validadores procesan uno por uno la lista de puntos de anclaje ordenados, ordenando los vértices desordenados anteriores en la historia causal de cada punto de anclaje.
La clave para satisfacer la seguridad es asegurar que en el paso (2), todas las listas de anclajes ordenados creadas por nodos de verificación honestos compartan el mismo prefijo. En Shoal, observamos que:
Todos los validadores acuerdan el primer punto de anclaje ordenado.
Bullshark retraso
La latencia de Bullshark depende del número de rondas entre los puntos de anclaje ordenados en el DAG. Las versiones de sincronización parcial tienen una latencia mejor que las versiones asíncronas, pero aún no son óptimas.
Pregunta 1: Retraso promedio de bloque. En Bullshark, hay un punto de anclaje en cada ronda par, y los vértices de la ronda impar se interpretan como votos. En situaciones comunes, se necesitan dos rondas de DAG para ordenar los puntos de anclaje, pero los vértices en la historia causal de los puntos de anclaje requieren más rondas de espera para que los puntos de anclaje sean ordenados. En situaciones comunes, los vértices de la ronda impar requieren tres rondas, y los vértices no anclados de la ronda par requieren cuatro rondas.
Pregunta 2: Retraso en la situación de fallos. Si un líder de ronda no logra transmitir el punto de anclaje a tiempo, no se puede ordenar ( se omite ), todos los vértices no ordenados de rondas anteriores deben esperar a que se ordene el siguiente punto de anclaje. Esto reduce significativamente el rendimiento de la red de replicación geográfica, especialmente porque Bullshark utiliza tiempos de espera para el líder.
Marco Shoal
Shoal mejora Bullshark( o cualquier protocolo BFT basado en Narwhal) mediante una línea de producción, permitiendo que en cada ronda haya 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íderes sin costo en el DAG, favoreciendo la selección de líderes rápidos.
desafío
En el protocolo DAG, la canalización y la reputación del líder se consideran problemas difíciles, por las siguientes razones:
Los intentos anteriores de modificar la lógica central de Bullshark en la línea de producción parecen ser, en esencia, imposibles.
La reputación de los líderes se introduce en DiemBFT y se formaliza en Carousel, eligiendo dinámicamente a los futuros líderes según el desempeño pasado de los validadores en (Bullshark. Aunque la divergencia en la identidad del líder no viola la seguridad de estos protocolos, en Bullshark podría resultar en un orden completamente diferente, lo que plantea el núcleo del problema: elegir de manera dinámica y determinista los anclajes de ronda es necesario para resolver el consenso, los validadores necesitan llegar a un acuerdo sobre la historia ordenada para seleccionar los futuros anclajes.
Como evidencia de la dificultad del problema, la implementación de Bullshark ) incluye que las ( actuales en el entorno de producción no admiten estas características.
) Acuerdo
A pesar de los desafíos mencionados, la solución se encuentra en la simplicidad.
Shoal se basa en la capacidad de realizar cálculos locales en el DAG, lo que permite guardar y reinterpretar la información de rondas anteriores. Basándose en la percepción de que todos los validadores están de acuerdo con el primer punto de anclaje ordenado, Shoal combina secuencialmente múltiples instancias de Bullshark para el procesamiento en paralelo, haciendo que ### el primer punto de anclaje ordenado sea el punto de cambio de las instancias, ( la historia causal del punto de anclaje 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 en orden, y el ancla de cada instancia está determinada previamente por el mapeo F. Cada instancia ordena un ancla, lo que provoca un cambio a la siguiente instancia.
Inicialmente, Shoal lanzó la primera instancia de Bullshark en la primera ronda de DAG, funcionando hasta que se determinó el primer punto de anclaje ordenado ( como la ronda r ). Todos los validadores acordaron este punto de anclaje, por lo que se puede acordar de manera firme reinterpretar el DAG a partir de la ronda r+1. Shoal lanzó una nueva instancia de Bullshark en la ronda r+1.
En el mejor de los casos, esto permite que Shoal ordene un ancla por ronda. El primer punto de anclaje es ordenado por la primera instancia. Luego, Shoal comienza una nueva instancia en la segunda ronda, tiene su propio punto de anclaje y es ordenado por esa instancia, luego otra nueva instancia ordena el punto de anclaje en la tercera ronda, y así 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-46d37add0d9e81b2f295edf8eddd907f.webp(
) Credibilidad del líder
Cuando el Bullshark omite puntos de anclaje, la latencia aumenta. En este caso, la tubería es impotente, ya que no se puede iniciar una nueva instancia antes de que se complete la ordenación del punto de anclaje anterior. Shoal asigna puntajes a cada nodo de validación mediante un mecanismo de reputación, asegurando que, según su historial de actividad reciente, es menos probable que se elija a un líder correspondiente para manejar los puntos de anclaje perdidos en el futuro. Los validadores que responden y participan en el protocolo obtienen puntajes altos, de lo contrario, se les asignan puntajes bajos ( pueden colapsar, ser lentos o actuar maliciosamente ).
La idea es recalcular de manera determinista el mapeo predefinido F desde la ronda hasta el líder cada vez que se actualizan los puntajes, favoreciendo a los líderes con puntajes altos. Para que los validadores lleguen a un consenso sobre el nuevo mapeo, deben llegar a un consenso sobre los puntajes, logrando así un consenso sobre la historia utilizada para derivar los puntajes.
En Shoal, la línea de producción y la reputación del líder se combinan de manera natural, ya que utilizan la misma tecnología central: reinterpretar el DAG después de alcanzar un consenso sobre el primer punto de anclaje ordenado.
La única diferencia es que, después del ancla de orden en la r-ésima ronda, los validadores calculan un nuevo mapeo F' a partir de la historia causal de los anclajes ordenados de la r-ésima ronda. Luego, los nodos de validación comienzan a ejecutar una nueva instancia de Bullshark utilizando la función de selección de anclajes actualizada F' a partir de la r+1-ésima ronda.
![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(
) No se requiere más tiempo de espera
El tiempo de espera es 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 necesitan ser gestionados y observados, lo que incrementa la complejidad del proceso de depuración y requiere más técnicas de observación.
Los tiempos de espera también aumentan significativamente la latencia, ya que es importante configurarlos adecuadamente, lo que a menudo requiere ajustes dinámicos y depende en gran medida del entorno ( y de la red ). Antes de transferir al siguiente líder, el protocolo paga la penalización completa por la latencia de tiempo de espera del líder con fallos. Por lo tanto, la configuración de los tiempos de espera no puede ser demasiado conservadora, pero si es demasiado corta, el protocolo puede saltarse a un buen líder. Por ejemplo, observamos que bajo alta carga, los líderes en Jolteon/Hotstuff se ven abrumados y el tiempo de espera ya ha expirado antes de que se logre el progreso.
Desafortunadamente, los protocolos basados en líderes ### como Hotstuff y Jolteon( requieren esencialmente un tiempo de espera para asegurar que el protocolo pueda avanzar cada vez que un líder falla. Sin un tiempo de espera, incluso un líder caído podría detener el protocolo para siempre. Dado que durante el periodo asincrónico no se puede distinguir entre un líder fallido y uno lento, el tiempo de espera puede llevar a que los nodos de validación vean cambios en 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 añadan puntos de anclaje al DAG a una velocidad lo suficientemente rápida como para ordenarlos.
Observamos que la construcción de DAG proporciona un "reloj" para estimar la velocidad de la red. Sin pausas, siempre que n-f validadores honestos continúen añadiendo vértices al DAG, la ronda seguirá 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 tengan problemas o la red esté asincrónica. Finalmente, cuando los líderes sin fallos transmiten lo suficientemente rápido los anclajes, toda la historia causal de los anclajes será ordenada.
En evaluación, comparamos si Bullshark tiene o no tiempo de espera en las siguientes situaciones:
Líder rápido, al menos más rápido que otros validadores. En este caso, ambos métodos ofrecen la misma latencia, ya que el ancla es ordenada y no utiliza tiempo de espera.
Líderes erróneos, en este caso, Bullshark sin pausa proporciona una mejor latencia, ya que los nodos de validación saltarán inmediatamente su punto de anclaje, mientras que los validadores con pausa esperarán a que caduquen antes de continuar.
Líderes lentos, esta es la única situación en la que el Bullshark tiene un mejor rendimiento en tiempo. Porque sin pausas, los puntos de anclaje pueden ser omitidos, ya que el líder no puede transmitirlo lo suficientemente rápido, y con pausas, los validadores esperarán los puntos de anclaje.
En Shoal, evitar el tiempo de espera está estrechamente relacionado con la reputación del líder. Esperar repetidamente.
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.
15 me gusta
Recompensa
15
7
Compartir
Comentar
0/400
MEVictim
· hace7h
La optimización ha mejorado significativamente la eficiencia.
Aptos introduce el marco Shoal, lo que reduce significativamente la latencia de Bullshark y elimina la necesidad de tiempos de espera.
Reducción de la latencia de Bullshark en Aptos: Explicación del marco Shoal
Aptos labs resolvió dos importantes problemas abiertos en DAG BFT, reduciendo significativamente la latencia y eliminando por primera vez la necesidad de pausas en los protocolos prácticos deterministas. En general, mejoró la latencia de Bullshark en un 40% en condiciones sin fallos y en un 80% en caso de fallos.
El marco Shoal mejora el protocolo de consenso basado en Narwhal ( a través de mecanismos de canalización y reputación de líderes, como DAG-Rider, Tusk, Bullshark ). La canalización introduce un punto de anclaje en cada ronda para reducir la latencia de ordenamiento de DAG, y la reputación del líder asegura que los puntos de anclaje estén asociados con los nodos de validación más rápidos, mejorando aún más la latencia. 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, logrando así propiedades de respuesta general.
La tecnología de Shoal es muy simple, ejecuta múltiples instancias del protocolo subyacente en orden. Cuando se instancia con Bullshark, es como un grupo de "tiburones" que están en una carrera de relevos.
Fondo
Al buscar un alto rendimiento en redes de blockchain, las personas siempre se han centrado en reducir la complejidad de la comunicación, pero esto no ha llevado a un aumento significativo en el rendimiento. Por ejemplo, el Hotstuff implementado en el temprano Diem solo alcanzó 3500 TPS, muy por debajo del objetivo de 100k+ TPS.
Recientemente, la ruptura 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, lo que puede beneficiarse de la paralelización. El sistema Narwhal separa la propagación de datos de la lógica de consenso central, todos los validadores propagan datos al mismo tiempo, y el componente de consenso solo ordena una pequeña cantidad de metadatos. El documento de Narwhal reportó una capacidad de 160,000 TPS.
Aptos presentó anteriormente Quorum Store, que es la implementación de Narwhal, separando la propagación de datos de la consenso, y se utiliza para escalar el protocolo de consenso actual Jolteon. Jolteon combina el camino rápido 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 plenamente el potencial de rendimiento de Narwhal.
Por lo tanto, Aptos decidió implementar Bullshark sobre el DAG de Narwhal, un protocolo de consenso sin costos de comunicación. Desafortunadamente, 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.
Contexto de DAG-BFT
Cada vértice en el DAG de Narwhal está relacionado con un número de ronda. Al entrar en la ronda r, un validador debe obtener n-f vértices de la ronda r-1. Cada validador puede transmitir un vértice por ronda, y cada vértice debe hacer referencia al menos a 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.
Una propiedad clave de DAG es que no es difusa: si dos nodos de validación tienen el mismo vértice v en su vista local de DAG, entonces tienen exactamente la misma historia causal de v.
Orden de secuencia
Se puede alcanzar un consenso sobre el orden total de todos los vértices en el DAG sin costos adicionales de comunicación. 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 grupal en la estructura DAG es diferente, todos los protocolos de consenso basados en Narwhal tienen la siguiente estructura:
Punto de anclaje: cada pocas rondas hay un líder preestablecido, cuyo vértice se llama punto de anclaje.
Puntos de anclaje de orden: los validadores deciden de manera independiente pero determinista qué puntos de anclaje ordenar y cuáles omitir.
Historia causal ordenada: los validadores procesan uno por uno la lista de puntos de anclaje ordenados, ordenando los vértices desordenados anteriores en la historia causal de cada punto de anclaje.
La clave para satisfacer la seguridad es asegurar que en el paso (2), todas las listas de anclajes ordenados creadas por nodos de verificación honestos compartan el mismo prefijo. En Shoal, observamos que:
Todos los validadores acuerdan el primer punto de anclaje ordenado.
Bullshark retraso
La latencia de Bullshark depende del número de rondas entre los puntos de anclaje ordenados en el DAG. Las versiones de sincronización parcial tienen una latencia mejor que las versiones asíncronas, pero aún no son óptimas.
Pregunta 1: Retraso promedio de bloque. En Bullshark, hay un punto de anclaje en cada ronda par, y los vértices de la ronda impar se interpretan como votos. En situaciones comunes, se necesitan dos rondas de DAG para ordenar los puntos de anclaje, pero los vértices en la historia causal de los puntos de anclaje requieren más rondas de espera para que los puntos de anclaje sean ordenados. En situaciones comunes, los vértices de la ronda impar requieren tres rondas, y los vértices no anclados de la ronda par requieren cuatro rondas.
Pregunta 2: Retraso en la situación de fallos. Si un líder de ronda no logra transmitir el punto de anclaje a tiempo, no se puede ordenar ( se omite ), todos los vértices no ordenados de rondas anteriores deben esperar a que se ordene el siguiente punto de anclaje. Esto reduce significativamente el rendimiento de la red de replicación geográfica, especialmente porque Bullshark utiliza tiempos de espera para el líder.
Marco Shoal
Shoal mejora Bullshark( o cualquier protocolo BFT basado en Narwhal) mediante una línea de producción, permitiendo que en cada ronda haya 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íderes sin costo en el DAG, favoreciendo la selección de líderes rápidos.
desafío
En el protocolo DAG, la canalización y la reputación del líder se consideran problemas difíciles, por las siguientes razones:
Los intentos anteriores de modificar la lógica central de Bullshark en la línea de producción parecen ser, en esencia, imposibles.
La reputación de los líderes se introduce en DiemBFT y se formaliza en Carousel, eligiendo dinámicamente a los futuros líderes según el desempeño pasado de los validadores en (Bullshark. Aunque la divergencia en la identidad del líder no viola la seguridad de estos protocolos, en Bullshark podría resultar en un orden completamente diferente, lo que plantea el núcleo del problema: elegir de manera dinámica y determinista los anclajes de ronda es necesario para resolver el consenso, los validadores necesitan llegar a un acuerdo sobre la historia ordenada para seleccionar los futuros anclajes.
Como evidencia de la dificultad del problema, la implementación de Bullshark ) incluye que las ( actuales en el entorno de producción no admiten estas características.
) Acuerdo
A pesar de los desafíos mencionados, la solución se encuentra en la simplicidad.
Shoal se basa en la capacidad de realizar cálculos locales en el DAG, lo que permite guardar y reinterpretar la información de rondas anteriores. Basándose en la percepción de que todos los validadores están de acuerdo con el primer punto de anclaje ordenado, Shoal combina secuencialmente múltiples instancias de Bullshark para el procesamiento en paralelo, haciendo que ### el primer punto de anclaje ordenado sea el punto de cambio de las instancias, ( la historia causal del punto de anclaje 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 en orden, y el ancla de cada instancia está determinada previamente por el mapeo F. Cada instancia ordena un ancla, lo que provoca un cambio a la siguiente instancia.
Inicialmente, Shoal lanzó la primera instancia de Bullshark en la primera ronda de DAG, funcionando hasta que se determinó el primer punto de anclaje ordenado ( como la ronda r ). Todos los validadores acordaron este punto de anclaje, por lo que se puede acordar de manera firme reinterpretar el DAG a partir de la ronda r+1. Shoal lanzó una nueva instancia de Bullshark en la ronda r+1.
En el mejor de los casos, esto permite que Shoal ordene un ancla por ronda. El primer punto de anclaje es ordenado por la primera instancia. Luego, Shoal comienza una nueva instancia en la segunda ronda, tiene su propio punto de anclaje y es ordenado por esa instancia, luego otra nueva instancia ordena el punto de anclaje en la tercera ronda, y así 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-46d37add0d9e81b2f295edf8eddd907f.webp(
) Credibilidad del líder
Cuando el Bullshark omite puntos de anclaje, la latencia aumenta. En este caso, la tubería es impotente, ya que no se puede iniciar una nueva instancia antes de que se complete la ordenación del punto de anclaje anterior. Shoal asigna puntajes a cada nodo de validación mediante un mecanismo de reputación, asegurando que, según su historial de actividad reciente, es menos probable que se elija a un líder correspondiente para manejar los puntos de anclaje perdidos en el futuro. Los validadores que responden y participan en el protocolo obtienen puntajes altos, de lo contrario, se les asignan puntajes bajos ( pueden colapsar, ser lentos o actuar maliciosamente ).
La idea es recalcular de manera determinista el mapeo predefinido F desde la ronda hasta el líder cada vez que se actualizan los puntajes, favoreciendo a los líderes con puntajes altos. Para que los validadores lleguen a un consenso sobre el nuevo mapeo, deben llegar a un consenso sobre los puntajes, logrando así un consenso sobre la historia utilizada para derivar los puntajes.
En Shoal, la línea de producción y la reputación del líder se combinan de manera natural, ya que utilizan la misma tecnología central: reinterpretar el DAG después de alcanzar un consenso sobre el primer punto de anclaje ordenado.
La única diferencia es que, después del ancla de orden en la r-ésima ronda, los validadores calculan un nuevo mapeo F' a partir de la historia causal de los anclajes ordenados de la r-ésima ronda. Luego, los nodos de validación comienzan a ejecutar una nueva instancia de Bullshark utilizando la función de selección de anclajes actualizada F' a partir de la r+1-ésima ronda.
![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(
) No se requiere más tiempo de espera
El tiempo de espera es 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 necesitan ser gestionados y observados, lo que incrementa la complejidad del proceso de depuración y requiere más técnicas de observación.
Los tiempos de espera también aumentan significativamente la latencia, ya que es importante configurarlos adecuadamente, lo que a menudo requiere ajustes dinámicos y depende en gran medida del entorno ( y de la red ). Antes de transferir al siguiente líder, el protocolo paga la penalización completa por la latencia de tiempo de espera del líder con fallos. Por lo tanto, la configuración de los tiempos de espera no puede ser demasiado conservadora, pero si es demasiado corta, el protocolo puede saltarse a un buen líder. Por ejemplo, observamos que bajo alta carga, los líderes en Jolteon/Hotstuff se ven abrumados y el tiempo de espera ya ha expirado antes de que se logre el progreso.
Desafortunadamente, los protocolos basados en líderes ### como Hotstuff y Jolteon( requieren esencialmente un tiempo de espera para asegurar que el protocolo pueda avanzar cada vez que un líder falla. Sin un tiempo de espera, incluso un líder caído podría detener el protocolo para siempre. Dado que durante el periodo asincrónico no se puede distinguir entre un líder fallido y uno lento, el tiempo de espera puede llevar a que los nodos de validación vean cambios en 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 añadan puntos de anclaje al DAG a una velocidad lo suficientemente rápida como para ordenarlos.
Observamos que la construcción de DAG proporciona un "reloj" para estimar la velocidad de la red. Sin pausas, siempre que n-f validadores honestos continúen añadiendo vértices al DAG, la ronda seguirá 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 tengan problemas o la red esté asincrónica. Finalmente, cuando los líderes sin fallos transmiten lo suficientemente rápido los anclajes, toda la historia causal de los anclajes será ordenada.
En evaluación, comparamos si Bullshark tiene o no tiempo de espera en las siguientes situaciones:
Líder rápido, al menos más rápido que otros validadores. En este caso, ambos métodos ofrecen la misma latencia, ya que el ancla es ordenada y no utiliza tiempo de espera.
Líderes erróneos, en este caso, Bullshark sin pausa proporciona una mejor latencia, ya que los nodos de validación saltarán inmediatamente su punto de anclaje, mientras que los validadores con pausa esperarán a que caduquen antes de continuar.
Líderes lentos, esta es la única situación en la que el Bullshark tiene un mejor rendimiento en tiempo. Porque sin pausas, los puntos de anclaje pueden ser omitidos, ya que el líder no puede transmitirlo lo suficientemente rápido, y con pausas, los validadores esperarán los puntos de anclaje.
En Shoal, evitar el tiempo de espera está estrechamente relacionado con la reputación del líder. Esperar repetidamente.