Marco Shoal: cómo Soltar la latencia de Bullshark en Aptos
Aptos labs resolvió dos importantes problemas abiertos en DAG BFT, reduciendo significativamente la latencia y eliminando por primera vez la necesidad de tiempo de espera en protocolos de consenso deterministas. En general, el marco Shoal mejoró la latencia de Bullshark en un 40% en condiciones sin fallos y en un 80% en condiciones de fallo.
Shoal es un marco que mejora el protocolo de consenso basado en Narwhal ( a través de pipelines y la reputación de líderes, como DAG-Rider, Tusk, Bullshark ). La pipeline reduce la latencia de ordenación de DAG al introducir un ancla en cada ronda, y la reputación del líder mejora aún más el problema de latencia al asegurar que el ancla esté asociada con los nodos de validación más rápidos. Además, la reputación del líder permite que Shoal aproveche la construcción de DAG asíncrona para eliminar los tiempos de espera en todos los escenarios. Esto permite que Shoal ofrezca una propiedad que llamamos respuesta universal, que contiene la respuesta optimista que normalmente se requiere.
La tecnología de Shoal es muy simple, implica ejecutar múltiples instancias del protocolo subyacente una tras otra en orden. Por lo tanto, cuando se instancia Bullshark, obtenemos un grupo de "tiburones" que participan en una carrera de relevos.
Fondo
Al buscar un alto rendimiento en redes de blockchain, las personas han prestado atención a 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 más de 100k TPS.
Los recientes avances provienen de la comprensión de que la propagación de datos es el principal cuello de botella basado en el protocolo de líderes, y 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 en la que todos los validadores propagan datos simultáneamente, mientras que el componente de consenso solo ordena una pequeña cantidad de metadatos. El documento de Narwhal informa de un rendimiento de 160,000 TPS.
Aptos presentó anteriormente Quorum Store, que es su implementación de Narwhal, separando la propagación de datos del consenso y utilizándose 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, lo que puede reducir 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. A pesar de separar la propagación de datos del consenso, a medida que aumenta el rendimiento, los líderes de Hotstuff/Jolteon siguen estando limitados.
Por lo tanto, Aptos decidió implementar Bullshark sobre el DAG de Narwhal, un protocolo de consenso sin costo de comunicación. Desafortunadamente, en comparación con Jolteon, la estructura de DAG que soporta un alto rendimiento de Bullshark conlleva un costo de latencia del 50%.
Este artículo presenta cómo Shoal reduce significativamente la latencia de Bullshark.
Fondo de DAG-BFT
Cada vértice en el DAG de Narwhal está asociado a una ronda. Para entrar en la ronda r, un validador debe primero obtener n-f vértices que pertenecen a la ronda r-1. Cada validador puede 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 de las propiedades clave del DAG no es ambigua: si dos nodos de validación tienen el mismo vértice v en su vista local del DAG, entonces tienen la misma historia causal de v.
Orden de secuencia
Se puede llegar a un consenso sobre el orden total de 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 las aristas representan votos.
Aunque la lógica de intersección de grupos en la estructura DAG es diferente, todos los protocolos de consenso basados en Narwhal existentes tienen la siguiente estructura:
Punto de anclaje reservado: cada pocas rondas (, como en dos rondas de Bullshark ), habrá un líder previamente determinado, el vértice del líder se llama punto de anclaje.
Puntos de anclaje de ordenación: los validadores deciden de manera independiente pero determinista qué puntos de anclaje ordenar y cuáles omitir.
orden de la historia causal: los validadores procesan uno a uno su lista de anclajes ordenados, y para cada anclaje, ordenan todos los vértices previos desordenados en su historia causal mediante algunas reglas deterministas.
La clave para cumplir con la seguridad es asegurar que en el paso anterior (2), todos los nodos de validación honestos creen una lista de anclajes ordenada, para que todas las listas compartan el mismo prefijo. En Shoal, se hacen las siguientes observaciones sobre todos los protocolos mencionados anteriormente:
Todos los validadores están de acuerdo con 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 tiene una mejor latencia en la versión sincronizada que en la asincrónica, aún está lejos de ser la óptima.
Pregunta 1: latencia promedio de bloques. En Bullshark, cada ronda par tiene un anclaje, y los vértices de cada ronda impar se interpretan como votos. En casos comunes, se requieren dos rondas de DAG para ordenar los anclajes; sin embargo, los vértices en la historia causal del anclaje requieren más rondas para esperar que el anclaje sea ordenado. En casos comunes, los vértices en rondas impares requieren tres rondas, mientras que los vértices no anclados en rondas pares requieren cuatro rondas.
Problema 2: latencia de casos de falla, el análisis de latencia anterior se aplica a situaciones sin fallas, por otro lado, si un líder de ronda no logra transmitir lo suficientemente rápido el ancla, no se puede ordenar el ancla ( y, por lo tanto, se salta ), por lo que todos los vértices no ordenados en las primeras rondas deben esperar a que se ordene el próximo ancla. Esto puede Soltar significativamente el rendimiento de la red de replicación geográfica, especialmente porque se utiliza un tiempo de espera de Bullshark para esperar al líder.
Marco de Shoal
Shoal resolvió estos dos problemas de latencia, mejorando Bullshark( o cualquier otro protocolo BFT basado en Narwhal) a través de un pipeline, permitiendo un punto de anclaje en cada ronda y reduciendo la latencia de todos los vértices no anclados en el DAG a tres rondas. Shoal también introdujo un mecanismo de reputación de líder de cero 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 tubería y del líder se considera un problema difícil, por las siguientes razones:
Las líneas de producción anteriores intentaron modificar la lógica central de Bullshark, pero esto parece ser esencialmente imposible.
La reputación del líder se introduce en DiemBFT y se formaliza en Carousel, seleccionando dinámicamente a los futuros líderes según el desempeño pasado de los validadores en la idea del ancla en Bullshark (. Aunque las discrepancias en la identidad del líder no violan la seguridad de estos protocolos, en Bullshark, pueden llevar a un ordenamiento completamente diferente, lo que plantea el núcleo del problema, es decir, que seleccionar anclas de rueda de manera dinámica y determinista es necesario para resolver el consenso, y los validadores necesitan llegar a un acuerdo sobre la historia ordenada para seleccionar futuras anclas.
Como evidencia de la dificultad del problema, la implementación de Bullshark, incluida la que actualmente se encuentra en un entorno de producción, no admite estas características.
![Explicación detallada del marco Shoal: ¿Cómo Soltar la latencia de Bullshark en Aptos?])https://img-cdn.gateio.im/webp-social/moments-0b0928cb6240e994c1514c75e080a4b2.webp(
Protocolo
A pesar de los desafíos mencionados, como dice el refrán, la solución se encuentra oculta detrás de lo simple.
En Shoal, dependemos de la capacidad de realizar cálculos locales en el DAG y hemos logrado la capacidad de guardar y reinterpretar la información de las rondas anteriores. Con la visión central de que todos los validadores acuerdan el primer ancla ordenada, Shoal combina secuencialmente múltiples instancias de Bullshark para procesarlas en una tubería, de modo que ) el primer ancla ordenada es el punto de cambio de las instancias, y ( la historia causal del ancla se utiliza para calcular la reputación del líder.
) línea de producción
V que mapea las rondas a los líderes. Shoal ejecuta instancias de Bullshark una tras otra, de modo que para cada instancia, el ancla es determinada previamente 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 la ejecutó 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 acordar con certeza reinterpretar el DAG a partir de la ronda r+1. Shoal simplemente 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 se ordena según 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 el punto de anclaje en la tercera ronda, y luego el proceso continúa.
reputación de líder
Durante el ordenamiento de Bullshark, al saltar puntos de anclaje, la latencia aumentará. En este caso, la tecnología de pipeline no puede hacer nada, ya que no se puede iniciar una nueva instancia antes de que se ordene el punto de anclaje de la instancia anterior. Shoal asegura que sea menos probable elegir a los líderes correspondientes para manejar los puntos de anclaje perdidos en el futuro, asignando una puntuación a cada nodo de validación según el historial de actividad reciente de cada nodo de validación mediante un mecanismo de reputación. Los validadores que responden y participan en el protocolo obtendrán una puntuación alta; de lo contrario, se asignará una puntuación baja 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 el puntaje, inclinándose hacia el líder con mayor puntaje. Para que los validadores lleguen a un consenso sobre el nuevo mapeo, deben alcanzar un consenso sobre el puntaje, logrando así un consenso sobre la historia utilizada para derivar el puntaje.
En Shoal, la canalización y la reputación del 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 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, basado en la historia causal de los puntos de anclaje ordenados en la ronda r. Luego, los nodos de validación utilizan la función de selección de puntos de anclaje actualizada F' para ejecutar una nueva instancia de Bullshark a partir de la ronda r+1.
no hay más tiempo de espera
El tiempo de espera juega un papel crucial 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 del proceso de depuración y requiere más técnicas de observabilidad.
El tiempo de espera también puede aumentar significativamente la latencia, ya que es muy importante configurarlos adecuadamente y a menudo requiere ajustes dinámicos, ya que depende en gran medida del entorno ( red ). Antes de transferirse al siguiente líder, el protocolo pagará una penalización completa por la latencia de tiempo de espera del líder fallido. Por lo tanto, la configuración del tiempo de espera no debe ser demasiado conservadora, pero si el tiempo de espera es demasiado corto, el protocolo podría
Ver originales
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.
9 me gusta
Recompensa
9
6
Compartir
Comentar
0/400
BridgeNomad
· hace17h
hmm... la latencia mejorada se ve bien, pero todavía necesito validar esos vectores de confianza, para ser honesto.
Ver originalesResponder0
BearMarketHustler
· hace18h
¡Vaya, Aptos es bastante capaz!
Ver originalesResponder0
Whale_Whisperer
· hace18h
Esta mejora es increíble, primero acumula algo de apt.
Ver originalesResponder0
CryptoMotivator
· hace18h
Aptos gogo～latencia 80% es realmente increíble
Ver originalesResponder0
StakeHouseDirector
· hace18h
experto, esta optimización de rendimiento es realmente impresionante.
Ver originalesResponder0
Layer2Observer
· hace18h
latencia elevar 80% es un poco hardcore, espero los datos de prueba
El marco Shoal reduce significativamente la latencia Bullshark en Aptos on-chain.
Marco Shoal: cómo Soltar la latencia de Bullshark en Aptos
Aptos labs resolvió dos importantes problemas abiertos en DAG BFT, reduciendo significativamente la latencia y eliminando por primera vez la necesidad de tiempo de espera en protocolos de consenso deterministas. En general, el marco Shoal mejoró la latencia de Bullshark en un 40% en condiciones sin fallos y en un 80% en condiciones de fallo.
Shoal es un marco que mejora el protocolo de consenso basado en Narwhal ( a través de pipelines y la reputación de líderes, como DAG-Rider, Tusk, Bullshark ). La pipeline reduce la latencia de ordenación de DAG al introducir un ancla en cada ronda, y la reputación del líder mejora aún más el problema de latencia al asegurar que el ancla esté asociada con los nodos de validación más rápidos. Además, la reputación del líder permite que Shoal aproveche la construcción de DAG asíncrona para eliminar los tiempos de espera en todos los escenarios. Esto permite que Shoal ofrezca una propiedad que llamamos respuesta universal, que contiene la respuesta optimista que normalmente se requiere.
La tecnología de Shoal es muy simple, implica ejecutar múltiples instancias del protocolo subyacente una tras otra en orden. Por lo tanto, cuando se instancia Bullshark, obtenemos un grupo de "tiburones" que participan en una carrera de relevos.
Fondo
Al buscar un alto rendimiento en redes de blockchain, las personas han prestado atención a 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 más de 100k TPS.
Los recientes avances provienen de la comprensión de que la propagación de datos es el principal cuello de botella basado en el protocolo de líderes, y 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 en la que todos los validadores propagan datos simultáneamente, mientras que el componente de consenso solo ordena una pequeña cantidad de metadatos. El documento de Narwhal informa de un rendimiento de 160,000 TPS.
Aptos presentó anteriormente Quorum Store, que es su implementación de Narwhal, separando la propagación de datos del consenso y utilizándose 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, lo que puede reducir 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. A pesar de separar la propagación de datos del consenso, a medida que aumenta el rendimiento, los líderes de Hotstuff/Jolteon siguen estando limitados.
Por lo tanto, Aptos decidió implementar Bullshark sobre el DAG de Narwhal, un protocolo de consenso sin costo de comunicación. Desafortunadamente, en comparación con Jolteon, la estructura de DAG que soporta un alto rendimiento de Bullshark conlleva un costo de latencia del 50%.
Este artículo presenta cómo Shoal reduce significativamente la latencia de Bullshark.
Fondo de DAG-BFT
Cada vértice en el DAG de Narwhal está asociado a una ronda. Para entrar en la ronda r, un validador debe primero obtener n-f vértices que pertenecen a la ronda r-1. Cada validador puede 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 de las propiedades clave del DAG no es ambigua: si dos nodos de validación tienen el mismo vértice v en su vista local del DAG, entonces tienen la misma historia causal de v.
Orden de secuencia
Se puede llegar a un consenso sobre el orden total de 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 las aristas representan votos.
Aunque la lógica de intersección de grupos en la estructura DAG es diferente, todos los protocolos de consenso basados en Narwhal existentes tienen la siguiente estructura:
Punto de anclaje reservado: cada pocas rondas (, como en dos rondas de Bullshark ), habrá un líder previamente determinado, el vértice del líder se llama punto de anclaje.
Puntos de anclaje de ordenación: los validadores deciden de manera independiente pero determinista qué puntos de anclaje ordenar y cuáles omitir.
orden de la historia causal: los validadores procesan uno a uno su lista de anclajes ordenados, y para cada anclaje, ordenan todos los vértices previos desordenados en su historia causal mediante algunas reglas deterministas.
La clave para cumplir con la seguridad es asegurar que en el paso anterior (2), todos los nodos de validación honestos creen una lista de anclajes ordenada, para que todas las listas compartan el mismo prefijo. En Shoal, se hacen las siguientes observaciones sobre todos los protocolos mencionados anteriormente:
Todos los validadores están de acuerdo con 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 tiene una mejor latencia en la versión sincronizada que en la asincrónica, aún está lejos de ser la óptima.
Pregunta 1: latencia promedio de bloques. En Bullshark, cada ronda par tiene un anclaje, y los vértices de cada ronda impar se interpretan como votos. En casos comunes, se requieren dos rondas de DAG para ordenar los anclajes; sin embargo, los vértices en la historia causal del anclaje requieren más rondas para esperar que el anclaje sea ordenado. En casos comunes, los vértices en rondas impares requieren tres rondas, mientras que los vértices no anclados en rondas pares requieren cuatro rondas.
Problema 2: latencia de casos de falla, el análisis de latencia anterior se aplica a situaciones sin fallas, por otro lado, si un líder de ronda no logra transmitir lo suficientemente rápido el ancla, no se puede ordenar el ancla ( y, por lo tanto, se salta ), por lo que todos los vértices no ordenados en las primeras rondas deben esperar a que se ordene el próximo ancla. Esto puede Soltar significativamente el rendimiento de la red de replicación geográfica, especialmente porque se utiliza un tiempo de espera de Bullshark para esperar al líder.
Marco de Shoal
Shoal resolvió estos dos problemas de latencia, mejorando Bullshark( o cualquier otro protocolo BFT basado en Narwhal) a través de un pipeline, permitiendo un punto de anclaje en cada ronda y reduciendo la latencia de todos los vértices no anclados en el DAG a tres rondas. Shoal también introdujo un mecanismo de reputación de líder de cero 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 tubería y del líder se considera un problema difícil, por las siguientes razones:
Las líneas de producción anteriores intentaron modificar la lógica central de Bullshark, pero esto parece ser esencialmente imposible.
La reputación del líder se introduce en DiemBFT y se formaliza en Carousel, seleccionando dinámicamente a los futuros líderes según el desempeño pasado de los validadores en la idea del ancla en Bullshark (. Aunque las discrepancias en la identidad del líder no violan la seguridad de estos protocolos, en Bullshark, pueden llevar a un ordenamiento completamente diferente, lo que plantea el núcleo del problema, es decir, que seleccionar anclas de rueda de manera dinámica y determinista es necesario para resolver el consenso, y los validadores necesitan llegar a un acuerdo sobre la historia ordenada para seleccionar futuras anclas.
Como evidencia de la dificultad del problema, la implementación de Bullshark, incluida la que actualmente se encuentra en un entorno de producción, no admite estas características.
![Explicación detallada del marco Shoal: ¿Cómo Soltar la latencia de Bullshark en Aptos?])https://img-cdn.gateio.im/webp-social/moments-0b0928cb6240e994c1514c75e080a4b2.webp(
Protocolo
A pesar de los desafíos mencionados, como dice el refrán, la solución se encuentra oculta detrás de lo simple.
En Shoal, dependemos de la capacidad de realizar cálculos locales en el DAG y hemos logrado la capacidad de guardar y reinterpretar la información de las rondas anteriores. Con la visión central de que todos los validadores acuerdan el primer ancla ordenada, Shoal combina secuencialmente múltiples instancias de Bullshark para procesarlas en una tubería, de modo que ) el primer ancla ordenada es el punto de cambio de las instancias, y ( la historia causal del ancla se utiliza para calcular la reputación del líder.
) línea de producción
V que mapea las rondas a los líderes. Shoal ejecuta instancias de Bullshark una tras otra, de modo que para cada instancia, el ancla es determinada previamente 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 la ejecutó 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 acordar con certeza reinterpretar el DAG a partir de la ronda r+1. Shoal simplemente 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 se ordena según 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 el punto de anclaje en la tercera ronda, y luego el proceso continúa.
reputación de líder
Durante el ordenamiento de Bullshark, al saltar puntos de anclaje, la latencia aumentará. En este caso, la tecnología de pipeline no puede hacer nada, ya que no se puede iniciar una nueva instancia antes de que se ordene el punto de anclaje de la instancia anterior. Shoal asegura que sea menos probable elegir a los líderes correspondientes para manejar los puntos de anclaje perdidos en el futuro, asignando una puntuación a cada nodo de validación según el historial de actividad reciente de cada nodo de validación mediante un mecanismo de reputación. Los validadores que responden y participan en el protocolo obtendrán una puntuación alta; de lo contrario, se asignará una puntuación baja 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 el puntaje, inclinándose hacia el líder con mayor puntaje. Para que los validadores lleguen a un consenso sobre el nuevo mapeo, deben alcanzar un consenso sobre el puntaje, logrando así un consenso sobre la historia utilizada para derivar el puntaje.
En Shoal, la canalización y la reputación del 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 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, basado en la historia causal de los puntos de anclaje ordenados en la ronda r. Luego, los nodos de validación utilizan la función de selección de puntos de anclaje actualizada F' para ejecutar una nueva instancia de Bullshark a partir de la ronda r+1.
no hay más tiempo de espera
El tiempo de espera juega un papel crucial 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 del proceso de depuración y requiere más técnicas de observabilidad.
El tiempo de espera también puede aumentar significativamente la latencia, ya que es muy importante configurarlos adecuadamente y a menudo requiere ajustes dinámicos, ya que depende en gran medida del entorno ( red ). Antes de transferirse al siguiente líder, el protocolo pagará una penalización completa por la latencia de tiempo de espera del líder fallido. Por lo tanto, la configuración del tiempo de espera no debe ser demasiado conservadora, pero si el tiempo de espera es demasiado corto, el protocolo podría