Marco Shoal: Innovadora solución para mejorar el rendimiento de la Cadena de bloques Aptos
Aptos Labs ha presentado recientemente el marco Shoal, que tiene como objetivo resolver dos problemas clave en el consenso DAG BFT, reduciendo significativamente la latencia y eliminando por primera vez la dependencia de los tiempos de espera en protocolos asíncronos deterministas. En general, Shoal mejora la latencia de Bullshark en un 40% en situaciones sin fallos y en un 80% en situaciones de fallo.
Shoal mejora el protocolo de consenso basado en Narwhal ( mediante el mecanismo de reputación del líder y la técnica de canalización, como DAG-Rider, Tusk, Bullshark, etc. La técnica de canalización reduce la latencia de ordenamiento de DAG al introducir un punto de anclaje en cada ronda, mientras que el mecanismo de 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 asincrónica para eliminar los tiempos de espera en todos los escenarios, logrando así una capacidad de respuesta universal.
La idea central de Shoal es ejecutar múltiples instancias del protocolo subyacente en orden. Tomemos Bullshark como ejemplo, se puede imaginar como un grupo de "tiburones" que están corriendo una carrera de relevos.
![Explicación detallada del marco Shoal: ¿Cómo reducir la latencia de Bullshark en Aptos?])https://img-cdn.gateio.im/webp-social/moments-8d6acd885bad7b8f911bdce15a7c884f.webp(
Motivación
La red de cadena de bloques ha estado buscando un rendimiento más alto, centrándose principalmente en reducir la complejidad de la comunicación en sus primeras etapas. Sin embargo, este enfoque no ha resultado en mejoras significativas en el rendimiento. Por ejemplo, Hotstuff, implementado en las primeras versiones de Diem, solo alcanzó 3500 TPS, muy por debajo del objetivo de más de 100,000 TPS.
El reciente avance se debe a la comprensión de que la propagación de datos es el principal cuello de botella basado en el protocolo de liderazgo, que 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 donde todos los validadores propagan datos simultáneamente, y el componente de consenso solo ordena una pequeña cantidad de metadatos, logrando un rendimiento de 160,000 TPS.
Aptos presentó anteriormente Quorum Store, que es la implementación de Narwhal, separando la propagación de datos y el consenso, y se utiliza para escalar el protocolo de consenso actual Jolteon. Jolteon 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, el protocolo de consenso basado en líderes no puede aprovechar plenamente el potencial de rendimiento de Narwhal.
Por lo tanto, Aptos decidió desplegar Bullshark sobre Narwhal DAG, un protocolo de consenso sin costo de comunicación. Sin embargo, la estructura DAG de alto rendimiento que soporta Bullshark conlleva un costo de latencia del 50%. El objetivo del marco Shoal es reducir drásticamente la latencia de Bullshark.
![Explicación detallada del marco Shoal: ¿cómo reducir la demora de Bullshark en Aptos?])https://img-cdn.gateio.im/webp-social/moments-f6b6281c928e3fa7a2412a480c9c1806.webp(
Fondo de DAG-BFT
Cada vértice en el DAG de Narwhal está asociado a una ronda. Para entrar en la ronda r, es necesario haber obtenido 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.
Una característica clave de DAG es la no ambigüedad: si dos nodos de validación tienen el mismo vértice v en su vista local de DAG, entonces poseen la misma historia causal completa de v.
![Explicación detallada del marco Shoal: ¿Cómo reducir la latencia de Bullshark en Aptos?])https://img-cdn.gateio.im/webp-social/moments-b7ed8888da112bae8d34c0fdb338b138.webp(
Ordenación total
Se puede llegar a un consenso sobre el orden total de todos los vértices en el DAG sin costos de comunicación adicionales. Protocolos como 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 específica es diferente, todos los protocolos de consenso basados en Narwhal tienen la siguiente estructura:
Punto de anclaje programado: cada pocas rondas hay un líder previamente determinado, cuyo vértice se llama punto de anclaje.
Puntos de anclaje de ordenación: los validadores deciden de manera independiente pero determinista qué puntos de anclaje ordenar o saltar.
Historia causal ordenada: los validadores procesan uno a uno la lista de anclajes ordenados, ordenando los vértices no ordenados previamente en la historia causal de cada anclaje.
La clave para satisfacer la seguridad es asegurar que todos los nodos de verificación honestos compartan la misma prefijo en la lista de puntos de anclaje ordenados que crean. Shoal hace una observación importante sobre todos estos protocolos: todos los validadores están de acuerdo en el primer punto de anclaje ordenado.
Problemas de retraso de Bullshark
La latencia de Bullshark depende del número de rondas entre los puntos de anclaje ordenados en el DAG. Aunque algunas versiones sincronizadas tienen una latencia más baja que las versiones asincrónicas, todavía están lejos de ser óptimas.
Principalmente existen dos problemas:
Retraso promedio de bloque: en casos comunes, los vértices impares de la ronda requieren tres rondas para ser ordenados, los vértices pares no ancla requieren cuatro rondas.
Situación de retraso por fallos: Si un líder de ronda no logra transmitir el ancla a tiempo, ese ancla será omitida y todos los vértices no ordenados de las rondas anteriores deben esperar a que se ordene el siguiente ancla. Esto reduce significativamente el rendimiento de la red distribuida geográficamente, especialmente porque Bullshark utiliza tiempo de espera para el 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(
Marco Shoal
Shoal a través de la línea de producción mejora Bullshark) o cualquier protocolo BFT basado en Narwhal(, permitiendo que en cada ronda haya un punto de anclaje, reduciendo la latencia de todos los vértices no ancla a tres rondas. Shoal también introduce un mecanismo de reputación de líder sin costo en el DAG, que tiende a seleccionar líderes rápidos.
) desafío
Se considera difícil implementar la canalización y la reputación del líder en el protocolo DAG:
Intentar modificar la lógica central de Bullshark anteriormente parece no ser viable.
La reputación de los líderes puede llevar a diferentes clasificaciones, y los validadores necesitan llegar a un consenso sobre la historia ordenada para elegir futuros puntos de anclaje.
Como evidencia de la dificultad del problema, las implementaciones de Bullshark en el entorno de producción actual no soportan estas características.
protocolo
La solución de Shoal es relativamente simple. Aprovecha la capacidad de realizar cálculos locales en un DAG, logrando la funcionalidad de guardar y reinterpretar la información de rondas anteriores. Basado en la percepción de que todos los validadores están de acuerdo con el primer ancla ordenada, Shoal combina secuencialmente múltiples instancias de Bullshark para el procesamiento en línea, lo que permite:
El primer punto de anclaje ordenado es el punto de cambio de la instancia
La historia causal del ancla se utiliza para calcular la reputación del líder
línea de producción
V que asigna los turnos a los líderes. Shoal ejecuta instancias de Bullshark en orden, cada instancia ordena un punto de anclaje y desencadena el cambio a la siguiente instancia.
Shoal inicia la primera instancia de Bullshark desde la primera ronda de DAG, hasta que se determina el primer punto de anclaje ordenado ### suponiendo en la ronda r (. Todos los validadores están de acuerdo con este punto de anclaje, por lo tanto se puede acordar de manera determinista reinterpretar el DAG desde la ronda r+1. Shoal inicia una nueva instancia de Bullshark en la ronda r+1.
En un escenario ideal, esto permite a Shoal ordenar un punto de anclaje por ronda. El primer punto de anclaje es ordenado por la primera instancia, luego en la segunda ronda, una nueva instancia ordena ese punto de anclaje de la ronda, y así sucesivamente.
![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 de los líderes
Cuando Bullshark salta sobre un punto de anclaje, la demora aumenta. La técnica de tuberías no puede hacer nada en este caso, porque es necesario esperar que la instancia anterior ordene el punto de anclaje para iniciar una nueva instancia. Shoal asigna puntajes a cada nodo de validación a través de un mecanismo de reputación, basado en su historial de actividad reciente. Los validadores que responden rápidamente obtienen puntuaciones altas, de lo contrario, obtienen puntuaciones bajas.
La idea es recalcular de manera determinista el mapeo F desde la ronda hasta el líder cada vez que se actualiza la puntuación, favoreciendo a los líderes de alta puntuación. Para que los validadores lleguen a un consenso sobre el nuevo mapeo, necesitan llegar a un consenso sobre la puntuación y, a su vez, llegar a un consenso sobre la historia utilizada para derivar la puntuación.
En Shoal, la reputación de la tubería y del líder puede combinarse de manera natural, ya que ambas se basan en la reinterpretación del DAG después de alcanzar un consenso en el primer punto de anclaje ordenado. La única diferencia es que, después del r-ésimo punto de anclaje ordenado, los validadores calculan un nuevo mapeo F' a partir del r+1-ésimo basándose en la historia causal de ese punto de anclaje. Luego, a partir del r+1-ésimo, se ejecutan nuevas instancias de Bullshark utilizando el F' actualizado.
![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(
) Eliminar tiempo de espera
El tiempo de espera es crucial en todas las implementaciones BFT deterministas basadas en líderes. Sin embargo, aumentan la complejidad, requieren más gestión del estado interno y observación, lo que dificulta la depuración.
El tiempo de espera también aumentará significativamente la latencia, ya que una configuración correcta es importante y generalmente necesita ajustes dinámicos. Antes de cambiar al siguiente líder, el protocolo debe pagar la penalización completa por el retraso del líder fallido. Por lo tanto, la configuración del tiempo de espera no puede ser demasiado conservadora, pero si es demasiado corta, podría saltarse a un buen líder.
Desafortunadamente, el protocolo basado en líderes ### como Hotstuff y Jolteon ( esencialmente requiere un tiempo de espera para garantizar el progreso en caso de fallos del líder. Sin un tiempo de espera, incluso un líder que ha fallado podría detener el protocolo para siempre. Dado que no se puede distinguir entre un fallo y un líder lento durante el período asíncrono, el tiempo de espera podría llevar a que los nodos de verificación reemplacen a 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. Siempre que n-f validadores honestos continúen agregando vértices al DAG, la ronda avanzará. Aunque Bullshark puede no ordenar a la velocidad de la red, el DAG aún crece a la velocidad de la red. Finalmente, cuando un líder sin fallos transmite lo suficientemente rápido el ancla, toda la historia causal del ancla será ordenada.
En la evaluación, comparamos Bullshark con y sin tiempo de espera:
Líder rápido: dos métodos tienen la misma demora, ya que los puntos de anclaje están ordenados y no se utiliza el tiempo de espera.
Líderes erróneos: Bullshark sin tiempo de espera, latencia más baja, ya que los nodos de validación saltarán inmediatamente su punto de anclaje.
Líderes lentos: tienen un rendimiento mejor que Bullshark con tiempo de espera, porque los validadores esperan el punto de anclaje, mientras que sin tiempo de espera pueden saltarse el punto de anclaje.
En Shoal, evitar el tiempo de espera está estrechamente relacionado con la reputación del líder. Esperar repetidamente a líderes lentos aumentará la latencia, mientras que el mecanismo de reputación excluye a los validadores lentos de ser elegidos como líderes. De esta manera, el sistema puede operar a la velocidad de la red en todos los escenarios reales.
Es importante tener en cuenta que el resultado de imposibilidad de FLP indica que no existe un protocolo de consenso determinista que pueda evitar completamente los tiempos de espera. Shoal no puede eludir este resultado, ya que teóricamente existen cronogramas de eventos adversos que pueden impedir que se ordenen todos los puntos de anclaje. En cambio, después de un número configurable de saltos de punto de anclaje, Shoal retrocederá a un tiempo de espera. Sin embargo, en la práctica, esta situación es muy poco probable que ocurra.
) Respuesta general
El artículo de Hotstuff popularizó el concepto de respuesta optimista, lo que intuitivamente significa que el protocolo puede funcionar a la velocidad de la red en buenas condiciones, incluyendo un líder rápido y una red sincronizada ###.
Shoal ofrece una mejor característica llamada respuesta universal. Específicamente, en comparación con Hotstuff, incluso si el líder falla en un número configurable de rondas continuas o la red experimenta períodos asíncronos, Shoal continuará funcionando a la velocidad de la red.
La capacidad de respuesta general proporciona una garantía de progreso mucho más estricta durante los períodos asíncronos y en caso de fallos del líder. Durante la sincronización con líderes lentos, estas características no se pueden comparar directamente, ya que dependen de la velocidad del líder. Sin embargo, dado el mecanismo de reputación del líder, los líderes lentos deberían aparecer raramente en Shoal.
Marco Shoal: Mejora del 40% de latencia de la cadena Aptos y eliminación de la dependencia de tiempo de espera
Marco Shoal: Innovadora solución para mejorar el rendimiento de la Cadena de bloques Aptos
Aptos Labs ha presentado recientemente el marco Shoal, que tiene como objetivo resolver dos problemas clave en el consenso DAG BFT, reduciendo significativamente la latencia y eliminando por primera vez la dependencia de los tiempos de espera en protocolos asíncronos deterministas. En general, Shoal mejora la latencia de Bullshark en un 40% en situaciones sin fallos y en un 80% en situaciones de fallo.
Shoal mejora el protocolo de consenso basado en Narwhal ( mediante el mecanismo de reputación del líder y la técnica de canalización, como DAG-Rider, Tusk, Bullshark, etc. La técnica de canalización reduce la latencia de ordenamiento de DAG al introducir un punto de anclaje en cada ronda, mientras que el mecanismo de 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 asincrónica para eliminar los tiempos de espera en todos los escenarios, logrando así una capacidad de respuesta universal.
La idea central de Shoal es ejecutar múltiples instancias del protocolo subyacente en orden. Tomemos Bullshark como ejemplo, se puede imaginar como un grupo de "tiburones" que están corriendo una carrera de relevos.
![Explicación detallada del marco Shoal: ¿Cómo reducir la latencia de Bullshark en Aptos?])https://img-cdn.gateio.im/webp-social/moments-8d6acd885bad7b8f911bdce15a7c884f.webp(
Motivación
La red de cadena de bloques ha estado buscando un rendimiento más alto, centrándose principalmente en reducir la complejidad de la comunicación en sus primeras etapas. Sin embargo, este enfoque no ha resultado en mejoras significativas en el rendimiento. Por ejemplo, Hotstuff, implementado en las primeras versiones de Diem, solo alcanzó 3500 TPS, muy por debajo del objetivo de más de 100,000 TPS.
El reciente avance se debe a la comprensión de que la propagación de datos es el principal cuello de botella basado en el protocolo de liderazgo, que 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 donde todos los validadores propagan datos simultáneamente, y el componente de consenso solo ordena una pequeña cantidad de metadatos, logrando un rendimiento de 160,000 TPS.
Aptos presentó anteriormente Quorum Store, que es la implementación de Narwhal, separando la propagación de datos y el consenso, y se utiliza para escalar el protocolo de consenso actual Jolteon. Jolteon 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, el protocolo de consenso basado en líderes no puede aprovechar plenamente el potencial de rendimiento de Narwhal.
Por lo tanto, Aptos decidió desplegar Bullshark sobre Narwhal DAG, un protocolo de consenso sin costo de comunicación. Sin embargo, la estructura DAG de alto rendimiento que soporta Bullshark conlleva un costo de latencia del 50%. El objetivo del marco Shoal es reducir drásticamente la latencia de Bullshark.
![Explicación detallada del marco Shoal: ¿cómo reducir la demora de Bullshark en Aptos?])https://img-cdn.gateio.im/webp-social/moments-f6b6281c928e3fa7a2412a480c9c1806.webp(
Fondo de DAG-BFT
Cada vértice en el DAG de Narwhal está asociado a una ronda. Para entrar en la ronda r, es necesario haber obtenido 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.
Una característica clave de DAG es la no ambigüedad: si dos nodos de validación tienen el mismo vértice v en su vista local de DAG, entonces poseen la misma historia causal completa de v.
![Explicación detallada del marco Shoal: ¿Cómo reducir la latencia de Bullshark en Aptos?])https://img-cdn.gateio.im/webp-social/moments-b7ed8888da112bae8d34c0fdb338b138.webp(
Ordenación total
Se puede llegar a un consenso sobre el orden total de todos los vértices en el DAG sin costos de comunicación adicionales. Protocolos como 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 específica es diferente, todos los protocolos de consenso basados en Narwhal tienen la siguiente estructura:
Punto de anclaje programado: cada pocas rondas hay un líder previamente determinado, cuyo vértice se llama punto de anclaje.
Puntos de anclaje de ordenación: los validadores deciden de manera independiente pero determinista qué puntos de anclaje ordenar o saltar.
Historia causal ordenada: los validadores procesan uno a uno la lista de anclajes ordenados, ordenando los vértices no ordenados previamente en la historia causal de cada anclaje.
La clave para satisfacer la seguridad es asegurar que todos los nodos de verificación honestos compartan la misma prefijo en la lista de puntos de anclaje ordenados que crean. Shoal hace una observación importante sobre todos estos protocolos: todos los validadores están de acuerdo en el primer punto de anclaje ordenado.
Problemas de retraso de Bullshark
La latencia de Bullshark depende del número de rondas entre los puntos de anclaje ordenados en el DAG. Aunque algunas versiones sincronizadas tienen una latencia más baja que las versiones asincrónicas, todavía están lejos de ser óptimas.
Principalmente existen dos problemas:
Retraso promedio de bloque: en casos comunes, los vértices impares de la ronda requieren tres rondas para ser ordenados, los vértices pares no ancla requieren cuatro rondas.
Situación de retraso por fallos: Si un líder de ronda no logra transmitir el ancla a tiempo, ese ancla será omitida y todos los vértices no ordenados de las rondas anteriores deben esperar a que se ordene el siguiente ancla. Esto reduce significativamente el rendimiento de la red distribuida geográficamente, especialmente porque Bullshark utiliza tiempo de espera para el 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(
Marco Shoal
Shoal a través de la línea de producción mejora Bullshark) o cualquier protocolo BFT basado en Narwhal(, permitiendo que en cada ronda haya un punto de anclaje, reduciendo la latencia de todos los vértices no ancla a tres rondas. Shoal también introduce un mecanismo de reputación de líder sin costo en el DAG, que tiende a seleccionar líderes rápidos.
) desafío
Se considera difícil implementar la canalización y la reputación del líder en el protocolo DAG:
Intentar modificar la lógica central de Bullshark anteriormente parece no ser viable.
La reputación de los líderes puede llevar a diferentes clasificaciones, y los validadores necesitan llegar a un consenso sobre la historia ordenada para elegir futuros puntos de anclaje.
Como evidencia de la dificultad del problema, las implementaciones de Bullshark en el entorno de producción actual no soportan estas características.
protocolo
La solución de Shoal es relativamente simple. Aprovecha la capacidad de realizar cálculos locales en un DAG, logrando la funcionalidad de guardar y reinterpretar la información de rondas anteriores. Basado en la percepción de que todos los validadores están de acuerdo con el primer ancla ordenada, Shoal combina secuencialmente múltiples instancias de Bullshark para el procesamiento en línea, lo que permite:
línea de producción
V que asigna los turnos a los líderes. Shoal ejecuta instancias de Bullshark en orden, cada instancia ordena un punto de anclaje y desencadena el cambio a la siguiente instancia.
Shoal inicia la primera instancia de Bullshark desde la primera ronda de DAG, hasta que se determina el primer punto de anclaje ordenado ### suponiendo en la ronda r (. Todos los validadores están de acuerdo con este punto de anclaje, por lo tanto se puede acordar de manera determinista reinterpretar el DAG desde la ronda r+1. Shoal inicia una nueva instancia de Bullshark en la ronda r+1.
En un escenario ideal, esto permite a Shoal ordenar un punto de anclaje por ronda. El primer punto de anclaje es ordenado por la primera instancia, luego en la segunda ronda, una nueva instancia ordena ese punto de anclaje de la ronda, y así sucesivamente.
![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 de los líderes
Cuando Bullshark salta sobre un punto de anclaje, la demora aumenta. La técnica de tuberías no puede hacer nada en este caso, porque es necesario esperar que la instancia anterior ordene el punto de anclaje para iniciar una nueva instancia. Shoal asigna puntajes a cada nodo de validación a través de un mecanismo de reputación, basado en su historial de actividad reciente. Los validadores que responden rápidamente obtienen puntuaciones altas, de lo contrario, obtienen puntuaciones bajas.
La idea es recalcular de manera determinista el mapeo F desde la ronda hasta el líder cada vez que se actualiza la puntuación, favoreciendo a los líderes de alta puntuación. Para que los validadores lleguen a un consenso sobre el nuevo mapeo, necesitan llegar a un consenso sobre la puntuación y, a su vez, llegar a un consenso sobre la historia utilizada para derivar la puntuación.
En Shoal, la reputación de la tubería y del líder puede combinarse de manera natural, ya que ambas se basan en la reinterpretación del DAG después de alcanzar un consenso en el primer punto de anclaje ordenado. La única diferencia es que, después del r-ésimo punto de anclaje ordenado, los validadores calculan un nuevo mapeo F' a partir del r+1-ésimo basándose en la historia causal de ese punto de anclaje. Luego, a partir del r+1-ésimo, se ejecutan nuevas instancias de Bullshark utilizando el F' actualizado.
![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(
) Eliminar tiempo de espera
El tiempo de espera es crucial en todas las implementaciones BFT deterministas basadas en líderes. Sin embargo, aumentan la complejidad, requieren más gestión del estado interno y observación, lo que dificulta la depuración.
El tiempo de espera también aumentará significativamente la latencia, ya que una configuración correcta es importante y generalmente necesita ajustes dinámicos. Antes de cambiar al siguiente líder, el protocolo debe pagar la penalización completa por el retraso del líder fallido. Por lo tanto, la configuración del tiempo de espera no puede ser demasiado conservadora, pero si es demasiado corta, podría saltarse a un buen líder.
Desafortunadamente, el protocolo basado en líderes ### como Hotstuff y Jolteon ( esencialmente requiere un tiempo de espera para garantizar el progreso en caso de fallos del líder. Sin un tiempo de espera, incluso un líder que ha fallado podría detener el protocolo para siempre. Dado que no se puede distinguir entre un fallo y un líder lento durante el período asíncrono, el tiempo de espera podría llevar a que los nodos de verificación reemplacen a 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. Siempre que n-f validadores honestos continúen agregando vértices al DAG, la ronda avanzará. Aunque Bullshark puede no ordenar a la velocidad de la red, el DAG aún crece a la velocidad de la red. Finalmente, cuando un líder sin fallos transmite lo suficientemente rápido el ancla, toda la historia causal del ancla será ordenada.
En la evaluación, comparamos Bullshark con y sin tiempo de espera:
Líder rápido: dos métodos tienen la misma demora, ya que los puntos de anclaje están ordenados y no se utiliza el tiempo de espera.
Líderes erróneos: Bullshark sin tiempo de espera, latencia más baja, ya que los nodos de validación saltarán inmediatamente su punto de anclaje.
Líderes lentos: tienen un rendimiento mejor que Bullshark con tiempo de espera, porque los validadores esperan el punto de anclaje, mientras que sin tiempo de espera pueden saltarse el punto de anclaje.
En Shoal, evitar el tiempo de espera está estrechamente relacionado con la reputación del líder. Esperar repetidamente a líderes lentos aumentará la latencia, mientras que el mecanismo de reputación excluye a los validadores lentos de ser elegidos como líderes. De esta manera, el sistema puede operar a la velocidad de la red en todos los escenarios reales.
Es importante tener en cuenta que el resultado de imposibilidad de FLP indica que no existe un protocolo de consenso determinista que pueda evitar completamente los tiempos de espera. Shoal no puede eludir este resultado, ya que teóricamente existen cronogramas de eventos adversos que pueden impedir que se ordenen todos los puntos de anclaje. En cambio, después de un número configurable de saltos de punto de anclaje, Shoal retrocederá a un tiempo de espera. Sin embargo, en la práctica, esta situación es muy poco probable que ocurra.
) Respuesta general
El artículo de Hotstuff popularizó el concepto de respuesta optimista, lo que intuitivamente significa que el protocolo puede funcionar a la velocidad de la red en buenas condiciones, incluyendo un líder rápido y una red sincronizada ###.
Shoal ofrece una mejor característica llamada respuesta universal. Específicamente, en comparación con Hotstuff, incluso si el líder falla en un número configurable de rondas continuas o la red experimenta períodos asíncronos, Shoal continuará funcionando a la velocidad de la red.
La capacidad de respuesta general proporciona una garantía de progreso mucho más estricta durante los períodos asíncronos y en caso de fallos del líder. Durante la sincronización con líderes lentos, estas características no se pueden comparar directamente, ya que dependen de la velocidad del líder. Sin embargo, dado el mecanismo de reputación del líder, los líderes lentos deberían aparecer raramente en Shoal.
![Explicación detallada de mil caracteres del marco Shoal: cómo reducir