Shoal框架:Gota significativa na latência do Bullshark na Aptos
Aptos Labs resolveu recentemente dois problemas abertos importantes no DAG BFT, reduzindo significativamente a Gota, e pela primeira vez eliminou a necessidade de timeouts em protocolos práticos determinísticos. No geral, melhorou a latência do Bullshark em 40% em situações sem falhas e em 80% em situações de falha.
Shoal é uma estrutura que, através de pipelines e da reputação dos líderes, melhora qualquer protocolo de consenso baseado em Narwhal ( como DAG-Rider, Tusk, Bullshark ). O pipeline reduz a latência de ordenação do DAG ao introduzir um ponto de ancoragem a cada rodada, enquanto a reputação do líder melhora ainda mais a latência ao garantir que o ponto de ancoragem esteja associado aos nós de validação mais rápidos. Além disso, a reputação do líder permite que o Shoal utilize a construção assíncrona do DAG para eliminar timeouts em todos os cenários. Isso permite que o Shoal forneça o que se chama de responsividade universal, que inclui a responsividade otimista normalmente necessária.
Esta tecnologia é bastante simples, envolvendo a execução em sequência de múltiplas instâncias de protocolos subjacentes. Assim, quando instanciamos com Bullshark, obtemos um grupo de "tubarões" a participar numa corrida de estafetas.
Motivação
Na busca por um alto desempenho da rede blockchain, as pessoas sempre se preocuparam em Gota a complexidade de comunicação. No entanto, esse método não resultou em um aumento significativo na taxa de transferência. Por exemplo, o Hotstuff implementado na versão inicial do Diem alcançou apenas 3500 TPS, muito abaixo da nossa meta de 100k+ TPS.
As últimas quebras vêm do reconhecimento de que a propagação de dados é o principal gargalo baseado em protocolos de liderança, podendo beneficiar-se da paralelização. O sistema Narwhal separa a propagação de dados da lógica de consenso central, propondo uma arquitetura onde todos os validadores propagam dados ao mesmo tempo, e o componente de consenso apenas ordena uma pequena quantidade de metadados. O artigo do Narwhal relatou uma taxa de transferência de 160.000 TPS.
No artigo anterior, apresentamos o Quorum Store. A nossa implementação do Narwhal separa a propagação de dados do consenso, e como utilizá-lo para escalar o protocolo de consenso atual Jolteon. Jolteon é um protocolo baseado em liderança, que combina o caminho linear rápido do Tendermint e a mudança de visão ao estilo PBFT, podendo reduzir a latência do Hotstuff em 33%. No entanto, é evidente que os protocolos de consenso baseados em liderança não conseguem aproveitar plenamente o potencial de throughput do Narwhal. Embora a propagação de dados e o consenso estejam separados, à medida que o throughput aumenta, os líderes do Hotstuff/Jolteon ainda estão limitados.
Portanto, decidimos implementar o Bullshark sobre o Narwhal DAG, um protocolo de consenso com zero sobrecarga de comunicação. Infelizmente, em comparação com o Jolteon, a estrutura DAG que suporta o Bullshark traz um custo de latência de 50%.
Este artigo apresenta como a Shoal conseguiu Gota significativamente a latência do Bullshark.
Background of DAG-BFT
Cada vértice no Narwhal DAG está associado a uma rodada. Para entrar na rodada r, o validador deve primeiro obter n-f vértices que pertencem à rodada r-1. Cada validador pode divulgar um vértice por rodada, e cada vértice deve referenciar pelo menos n-f vértices da rodada anterior. Devido à assíncronia da rede, diferentes validadores podem observar diferentes visões locais do DAG em qualquer momento.
Uma característica chave do DAG é que não é ambígua: se dois nós de validação têm o mesmo vértice v em sua visão local do DAG, então eles têm exatamente a mesma história causal de v.
Prefácio
É possível chegar a um consenso sobre a ordem total de todos os vértices no DAG sem custos adicionais de comunicação. Para isso, os validadores no DAG-Rider, Tusk e Bullshark interpretam a estrutura do DAG como um protocolo de consenso, onde os vértices representam propostas e as arestas representam votos.
Embora a lógica de interseção de grupos na estrutura DAG seja diferente, todos os protocolos de consenso existentes baseados no Narwhal possuem a seguinte estrutura:
Ponto de âncora pré-definido: a cada algumas rodadas (, por exemplo, em Bullshark, há um líder pré-determinado a cada duas rodadas ), e o pico do líder é chamado de ponto de âncora;
Pontos âncora de ordenação: os validadores decidem de forma independente, mas determinística, quais pontos âncora ordenar e quais pular;
História causal ordenada: os validadores processam um a um a lista de âncoras ordenadas, para cada âncora, classificando todos os vértices anteriores desordenados em sua história causal de acordo com algumas regras determinísticas.
A chave para garantir a segurança é assegurar que, no passo (2), todos os nós de validação honestos criem uma lista de âncoras ordenada, de modo que todas as listas compartilhem o mesmo prefixo. No Shoal, fazemos as seguintes observações sobre todos os protocolos acima mencionados:
Todos os validadores concordam com o primeiro ponto de ancoragem ordenado.
Bullshark latência
A latência do Bullshark depende do número de voltas entre os pontos âncora ordenados no DAG. Embora a versão sincronizada mais prática do Bullshark tenha uma latência melhor do que a versão assíncrona, ainda está longe de ser a ideal.
Pergunta 1: latência média de bloco. No Bullshark, cada rodada par tem um ponto de ancoragem, enquanto os vértices da rodada ímpar são interpretados como votos. Em situações comuns, são necessárias duas rodadas de DAG para ordenar pontos de ancoragem; no entanto, os vértices na história causal do anchor precisam de mais rodadas para esperar que o anchor seja ordenado. Em situações comuns, os vértices na rodada ímpar precisam de três rodadas, enquanto os vértices não ancorados na rodada par precisam de quatro rodadas.
Pergunta 2: Caso de falha de latência. A análise de latência acima aplica-se a uma situação sem falhas; por outro lado, se o líder de uma rodada não conseguir transmitir os pontos âncora rapidamente o suficiente, não será possível ordenar os pontos âncora (, portanto, eles serão ignorados ), e todos os vértices não ordenados nas rodadas anteriores terão que aguardar que o próximo ponto âncora seja ordenado. Isso pode Gota significativamente o desempenho da rede de replicação geográfica, especialmente porque o Bullshark utiliza um tempo limite para esperar pelo líder.
Estrutura Shoal
Shoal resolveu esses dois problemas de latência, melhorando o Bullshark( ou qualquer outro protocolo BFT baseado em Narwhal) através de um pipeline, permitindo que houvesse um ponto de ancoragem em cada rodada e reduzindo a latência de todos os vértices não ancorados no DAG para três rodadas. Shoal também introduziu um mecanismo de reputação de líder de zero custo no DAG, o que faz com que a escolha se incline para líderes rápidos.
Desafio
No contexto do protocolo DAG, a pipeline e a reputação do líder são consideradas questões difíceis, pelos seguintes motivos:
As tentativas anteriores de pipeline tentaram modificar a lógica central do Bullshark, mas isso parece ser essencialmente impossível.
A reputação dos líderes é introduzida no DiemBFT e formalizada no Carousel, sendo selecionada dinamicamente com base no desempenho passado dos validadores para escolher os futuros líderes dos âncoras no Bullshark (. Embora a divergência na identidade do líder não viole a segurança destes protocolos, no Bullshark, isso pode levar a uma ordenação completamente diferente, o que leva ao cerne da questão, ou seja, a escolha dinâmica e determinística dos âncoras é necessária para resolver o consenso, e os validadores precisam chegar a um acordo sobre a história ordenada para escolher os futuros âncoras.
Como evidência da dificuldade do problema, notamos que a implementação do Bullshark, incluindo a implementação atualmente em ambiente de produção, não suporta essas características.
Acordo
Apesar dos desafios mencionados acima, a verdade é que a solução se encontra na simplicidade.
No Shoal, dependemos da capacidade de executar cálculos locais sobre o DAG e implementamos a capacidade de salvar e reinterpretar informações das rodadas anteriores. Com a visão central de que todos os validadores concordam com o primeiro ponto de ancoragem ordenado, o Shoal combina sequencialmente várias instâncias de Bullshark para processá-las em pipeline, fazendo com que ) o primeiro ponto de ancoragem ordenado seja o ponto de mudança das instâncias, e ( a história causal do ponto de ancoragem é usada para calcular a reputação dos líderes.
V que mapeia as rodadas para os líderes. Shoal executa instâncias do Bullshark uma após a outra, de modo que para cada instância, a âncora é previamente determinada pelo mapeamento F. Cada instância solicita uma âncora, o que desencadeia a mudança para a próxima instância.
No início, Shoal lançou a primeira instância do Bullshark na primeira rodada do DAG e a executou até determinar o primeiro ponto âncora ordenado, como na rodada r. Todos os validadores concordaram com este ponto âncora. Portanto, todos os validadores podem concordar de forma confiável em reinterpretar o DAG a partir da rodada r+1. Shoal apenas lançou uma nova instância do Bullshark na rodada r+1.
No melhor cenário, isso permite que o Shoal encomende uma âncora em cada rodada. Os pontos de âncora da primeira rodada são ordenados pela primeira instância. Em seguida, o Shoal inicia uma nova instância na segunda rodada, que por sua vez tem um ponto de âncora, que é ordenado por essa instância, e então, outra nova instância encomenda o ponto de âncora na terceira rodada, e o processo continua.
Durante o período de ordenação do Bullshark, a latência aumenta ao pular âncoras. Nesse caso, a tecnologia de pipeline não pode ajudar, pois não é possível iniciar uma nova instância antes que a âncora da instância anterior seja encomendada. O Shoal assegura que é menos provável que o líder correspondente seja escolhido para lidar com âncoras perdidas no futuro, atribuindo uma pontuação a cada nó de validação com base no histórico da atividade recente de cada nó de validação, através do uso de um mecanismo de reputação. Os validadores que respondem e participam do protocolo receberão uma pontuação alta; caso contrário, os nós de validação receberão uma pontuação baixa, pois podem estar em colapso, lentos ou agindo de forma maliciosa.
A sua filosofia é recalcular de forma determinística o mapeamento predefinido F de cada rodada ao líder sempre que a pontuação for atualizada, favorecendo os líderes com pontuações mais altas. Para que os validadores cheguem a um consenso sobre o novo mapeamento, eles devem chegar a um consenso sobre a pontuação, alcançando assim um consenso sobre a história utilizada para derivar a pontuação.
No Shoal, a linha de produção e a reputação de liderança podem se combinar naturalmente, pois ambas usam a mesma tecnologia central, que é reinterpretar o DAG após alcançar um consenso sobre o primeiro ponto âncora ordenado.
Na verdade, a única diferença é que, após a ordenação dos âncoras na r-ésima rodada, os validadores apenas precisam calcular um novo mapeamento F' a partir da r+1-ésima rodada, com base na história causal das âncoras ordenadas da r-ésima rodada. Em seguida, os nós de validação começam a executar uma nova instância do Bullshark a partir da r+1-ésima rodada usando a função de seleção de âncoras atualizada F'.
O tempo limite desempenha um papel crucial em todas as implementações BFT determinísticas baseadas em líder. No entanto, a complexidade que elas introduzem aumenta o número de estados internos que precisam ser geridos e observados, o que aumenta a complexidade do processo de depuração e requer mais técnicas de observabilidade.
O Timeout também pode aumentar significativamente a latência, uma vez que é muito importante configurá-los adequadamente, e geralmente requer ajustes dinâmicos, pois depende muito do ambiente ) da rede (. Antes de passar para o próximo líder, o protocolo pagará a penalização completa do tempo de latência para o líder com falha. Portanto, a configuração do tempo limite não pode ser excessivamente conservadora, mas se o tempo limite for muito curto, o protocolo pode ignorar bons líderes. Por exemplo, observamos que, em situações de alta carga, Jolteon/
Esta página pode conter conteúdos de terceiros, que são fornecidos apenas para fins informativos (sem representações/garantias) e não devem ser considerados como uma aprovação dos seus pontos de vista pela Gate, nem como aconselhamento financeiro ou profissional. Consulte a Declaração de exoneração de responsabilidade para obter mais informações.
22 gostos
Recompensa
22
5
Partilhar
Comentar
0/400
BlockchainFries
· 07-21 02:44
Espera, 40% e ainda 80%. Tens a certeza de que não é só uma ilusão?
Ver originalResponder0
YouMustMakeBigMoneyEvery
· 07-20 12:23
Ainda não empreender um grande esforço. Muito pestilento. Romper 6 euros e aumentar a posição.
Ver originalResponder0
HalfBuddhaMoney
· 07-20 09:59
A latência caiu tanto, o aptos é muito promissor!
Ver originalResponder0
SleepyArbCat
· 07-20 09:58
Esta manhã já está quase a amanhecer, finalmente o aptos empreendeu um grande esforço, meow... a latência se ficar mais baixa já dá para comer de graça.
Ver originalResponder0
GasFeeCrying
· 07-20 09:55
latência reduzida em 40, esta onda está garantida.
A estrutura Shoal Gota a latência do Aptos Bullshark de 40%-80%
Shoal框架:Gota significativa na latência do Bullshark na Aptos
Aptos Labs resolveu recentemente dois problemas abertos importantes no DAG BFT, reduzindo significativamente a Gota, e pela primeira vez eliminou a necessidade de timeouts em protocolos práticos determinísticos. No geral, melhorou a latência do Bullshark em 40% em situações sem falhas e em 80% em situações de falha.
Shoal é uma estrutura que, através de pipelines e da reputação dos líderes, melhora qualquer protocolo de consenso baseado em Narwhal ( como DAG-Rider, Tusk, Bullshark ). O pipeline reduz a latência de ordenação do DAG ao introduzir um ponto de ancoragem a cada rodada, enquanto a reputação do líder melhora ainda mais a latência ao garantir que o ponto de ancoragem esteja associado aos nós de validação mais rápidos. Além disso, a reputação do líder permite que o Shoal utilize a construção assíncrona do DAG para eliminar timeouts em todos os cenários. Isso permite que o Shoal forneça o que se chama de responsividade universal, que inclui a responsividade otimista normalmente necessária.
Esta tecnologia é bastante simples, envolvendo a execução em sequência de múltiplas instâncias de protocolos subjacentes. Assim, quando instanciamos com Bullshark, obtemos um grupo de "tubarões" a participar numa corrida de estafetas.
Motivação
Na busca por um alto desempenho da rede blockchain, as pessoas sempre se preocuparam em Gota a complexidade de comunicação. No entanto, esse método não resultou em um aumento significativo na taxa de transferência. Por exemplo, o Hotstuff implementado na versão inicial do Diem alcançou apenas 3500 TPS, muito abaixo da nossa meta de 100k+ TPS.
As últimas quebras vêm do reconhecimento de que a propagação de dados é o principal gargalo baseado em protocolos de liderança, podendo beneficiar-se da paralelização. O sistema Narwhal separa a propagação de dados da lógica de consenso central, propondo uma arquitetura onde todos os validadores propagam dados ao mesmo tempo, e o componente de consenso apenas ordena uma pequena quantidade de metadados. O artigo do Narwhal relatou uma taxa de transferência de 160.000 TPS.
No artigo anterior, apresentamos o Quorum Store. A nossa implementação do Narwhal separa a propagação de dados do consenso, e como utilizá-lo para escalar o protocolo de consenso atual Jolteon. Jolteon é um protocolo baseado em liderança, que combina o caminho linear rápido do Tendermint e a mudança de visão ao estilo PBFT, podendo reduzir a latência do Hotstuff em 33%. No entanto, é evidente que os protocolos de consenso baseados em liderança não conseguem aproveitar plenamente o potencial de throughput do Narwhal. Embora a propagação de dados e o consenso estejam separados, à medida que o throughput aumenta, os líderes do Hotstuff/Jolteon ainda estão limitados.
Portanto, decidimos implementar o Bullshark sobre o Narwhal DAG, um protocolo de consenso com zero sobrecarga de comunicação. Infelizmente, em comparação com o Jolteon, a estrutura DAG que suporta o Bullshark traz um custo de latência de 50%.
Este artigo apresenta como a Shoal conseguiu Gota significativamente a latência do Bullshark.
Background of DAG-BFT
Cada vértice no Narwhal DAG está associado a uma rodada. Para entrar na rodada r, o validador deve primeiro obter n-f vértices que pertencem à rodada r-1. Cada validador pode divulgar um vértice por rodada, e cada vértice deve referenciar pelo menos n-f vértices da rodada anterior. Devido à assíncronia da rede, diferentes validadores podem observar diferentes visões locais do DAG em qualquer momento.
Uma característica chave do DAG é que não é ambígua: se dois nós de validação têm o mesmo vértice v em sua visão local do DAG, então eles têm exatamente a mesma história causal de v.
Prefácio
É possível chegar a um consenso sobre a ordem total de todos os vértices no DAG sem custos adicionais de comunicação. Para isso, os validadores no DAG-Rider, Tusk e Bullshark interpretam a estrutura do DAG como um protocolo de consenso, onde os vértices representam propostas e as arestas representam votos.
Embora a lógica de interseção de grupos na estrutura DAG seja diferente, todos os protocolos de consenso existentes baseados no Narwhal possuem a seguinte estrutura:
Ponto de âncora pré-definido: a cada algumas rodadas (, por exemplo, em Bullshark, há um líder pré-determinado a cada duas rodadas ), e o pico do líder é chamado de ponto de âncora;
Pontos âncora de ordenação: os validadores decidem de forma independente, mas determinística, quais pontos âncora ordenar e quais pular;
História causal ordenada: os validadores processam um a um a lista de âncoras ordenadas, para cada âncora, classificando todos os vértices anteriores desordenados em sua história causal de acordo com algumas regras determinísticas.
A chave para garantir a segurança é assegurar que, no passo (2), todos os nós de validação honestos criem uma lista de âncoras ordenada, de modo que todas as listas compartilhem o mesmo prefixo. No Shoal, fazemos as seguintes observações sobre todos os protocolos acima mencionados:
Todos os validadores concordam com o primeiro ponto de ancoragem ordenado.
Bullshark latência
A latência do Bullshark depende do número de voltas entre os pontos âncora ordenados no DAG. Embora a versão sincronizada mais prática do Bullshark tenha uma latência melhor do que a versão assíncrona, ainda está longe de ser a ideal.
Pergunta 1: latência média de bloco. No Bullshark, cada rodada par tem um ponto de ancoragem, enquanto os vértices da rodada ímpar são interpretados como votos. Em situações comuns, são necessárias duas rodadas de DAG para ordenar pontos de ancoragem; no entanto, os vértices na história causal do anchor precisam de mais rodadas para esperar que o anchor seja ordenado. Em situações comuns, os vértices na rodada ímpar precisam de três rodadas, enquanto os vértices não ancorados na rodada par precisam de quatro rodadas.
Pergunta 2: Caso de falha de latência. A análise de latência acima aplica-se a uma situação sem falhas; por outro lado, se o líder de uma rodada não conseguir transmitir os pontos âncora rapidamente o suficiente, não será possível ordenar os pontos âncora (, portanto, eles serão ignorados ), e todos os vértices não ordenados nas rodadas anteriores terão que aguardar que o próximo ponto âncora seja ordenado. Isso pode Gota significativamente o desempenho da rede de replicação geográfica, especialmente porque o Bullshark utiliza um tempo limite para esperar pelo líder.
Estrutura Shoal
Shoal resolveu esses dois problemas de latência, melhorando o Bullshark( ou qualquer outro protocolo BFT baseado em Narwhal) através de um pipeline, permitindo que houvesse um ponto de ancoragem em cada rodada e reduzindo a latência de todos os vértices não ancorados no DAG para três rodadas. Shoal também introduziu um mecanismo de reputação de líder de zero custo no DAG, o que faz com que a escolha se incline para líderes rápidos.
Desafio
No contexto do protocolo DAG, a pipeline e a reputação do líder são consideradas questões difíceis, pelos seguintes motivos:
As tentativas anteriores de pipeline tentaram modificar a lógica central do Bullshark, mas isso parece ser essencialmente impossível.
A reputação dos líderes é introduzida no DiemBFT e formalizada no Carousel, sendo selecionada dinamicamente com base no desempenho passado dos validadores para escolher os futuros líderes dos âncoras no Bullshark (. Embora a divergência na identidade do líder não viole a segurança destes protocolos, no Bullshark, isso pode levar a uma ordenação completamente diferente, o que leva ao cerne da questão, ou seja, a escolha dinâmica e determinística dos âncoras é necessária para resolver o consenso, e os validadores precisam chegar a um acordo sobre a história ordenada para escolher os futuros âncoras.
Como evidência da dificuldade do problema, notamos que a implementação do Bullshark, incluindo a implementação atualmente em ambiente de produção, não suporta essas características.
Acordo
Apesar dos desafios mencionados acima, a verdade é que a solução se encontra na simplicidade.
No Shoal, dependemos da capacidade de executar cálculos locais sobre o DAG e implementamos a capacidade de salvar e reinterpretar informações das rodadas anteriores. Com a visão central de que todos os validadores concordam com o primeiro ponto de ancoragem ordenado, o Shoal combina sequencialmente várias instâncias de Bullshark para processá-las em pipeline, fazendo com que ) o primeiro ponto de ancoragem ordenado seja o ponto de mudança das instâncias, e ( a história causal do ponto de ancoragem é usada para calcular a reputação dos líderes.
![万字详解Shoal框架：如何减少Aptos上的Bullshark Gota？])https://img-cdn.gateio.im/webp-social/moments-0b0928cb6240e994c1514c75e080a4b2.webp(
Linha de Produção
V que mapeia as rodadas para os líderes. Shoal executa instâncias do Bullshark uma após a outra, de modo que para cada instância, a âncora é previamente determinada pelo mapeamento F. Cada instância solicita uma âncora, o que desencadeia a mudança para a próxima instância.
No início, Shoal lançou a primeira instância do Bullshark na primeira rodada do DAG e a executou até determinar o primeiro ponto âncora ordenado, como na rodada r. Todos os validadores concordaram com este ponto âncora. Portanto, todos os validadores podem concordar de forma confiável em reinterpretar o DAG a partir da rodada r+1. Shoal apenas lançou uma nova instância do Bullshark na rodada r+1.
No melhor cenário, isso permite que o Shoal encomende uma âncora em cada rodada. Os pontos de âncora da primeira rodada são ordenados pela primeira instância. Em seguida, o Shoal inicia uma nova instância na segunda rodada, que por sua vez tem um ponto de âncora, que é ordenado por essa instância, e então, outra nova instância encomenda o ponto de âncora na terceira rodada, e o processo continua.
![万字详解Shoal框架：如何减少Aptos上的Bullshark Gota？])https://img-cdn.gateio.im/webp-social/moments-859e732e16c3eee0e2c93422474debc2.webp(
Reputação do Líder
Durante o período de ordenação do Bullshark, a latência aumenta ao pular âncoras. Nesse caso, a tecnologia de pipeline não pode ajudar, pois não é possível iniciar uma nova instância antes que a âncora da instância anterior seja encomendada. O Shoal assegura que é menos provável que o líder correspondente seja escolhido para lidar com âncoras perdidas no futuro, atribuindo uma pontuação a cada nó de validação com base no histórico da atividade recente de cada nó de validação, através do uso de um mecanismo de reputação. Os validadores que respondem e participam do protocolo receberão uma pontuação alta; caso contrário, os nós de validação receberão uma pontuação baixa, pois podem estar em colapso, lentos ou agindo de forma maliciosa.
A sua filosofia é recalcular de forma determinística o mapeamento predefinido F de cada rodada ao líder sempre que a pontuação for atualizada, favorecendo os líderes com pontuações mais altas. Para que os validadores cheguem a um consenso sobre o novo mapeamento, eles devem chegar a um consenso sobre a pontuação, alcançando assim um consenso sobre a história utilizada para derivar a pontuação.
No Shoal, a linha de produção e a reputação de liderança podem se combinar naturalmente, pois ambas usam a mesma tecnologia central, que é reinterpretar o DAG após alcançar um consenso sobre o primeiro ponto âncora ordenado.
Na verdade, a única diferença é que, após a ordenação dos âncoras na r-ésima rodada, os validadores apenas precisam calcular um novo mapeamento F' a partir da r+1-ésima rodada, com base na história causal das âncoras ordenadas da r-ésima rodada. Em seguida, os nós de validação começam a executar uma nova instância do Bullshark a partir da r+1-ésima rodada usando a função de seleção de âncoras atualizada F'.
![万字详解Shoal框架：如何减少Aptos上的Bullshark Gota？])https://img-cdn.gateio.im/webp-social/moments-9f789cb669f6fcc244ea7ff7648e48b4.webp(
Sem mais tempo limite
O tempo limite desempenha um papel crucial em todas as implementações BFT determinísticas baseadas em líder. No entanto, a complexidade que elas introduzem aumenta o número de estados internos que precisam ser geridos e observados, o que aumenta a complexidade do processo de depuração e requer mais técnicas de observabilidade.
O Timeout também pode aumentar significativamente a latência, uma vez que é muito importante configurá-los adequadamente, e geralmente requer ajustes dinâmicos, pois depende muito do ambiente ) da rede (. Antes de passar para o próximo líder, o protocolo pagará a penalização completa do tempo de latência para o líder com falha. Portanto, a configuração do tempo limite não pode ser excessivamente conservadora, mas se o tempo limite for muito curto, o protocolo pode ignorar bons líderes. Por exemplo, observamos que, em situações de alta carga, Jolteon/