Shoal框架: como Gota a latência do Bullshark na Aptos
Aptos labs resolveu dois importantes problemas abertos no DAG BFT, reduzindo significativamente a latência e eliminando pela primeira vez a necessidade de timeouts em protocolos determinísticos reais. De forma geral, a estrutura Shoal melhorou a latência do Bullshark em 40% em situações sem falhas e em 80% em situações de falha.
Shoal é um framework que aprimora o protocolo de consenso baseado em Narwhal ( por meio de pipeline e reputação de líderes, como DAG-Rider, Tusk, Bullshark ). O pipeline reduz a Gota de ordenação do DAG ao introduzir um ponto âncora a cada rodada, enquanto a reputação de líderes melhora ainda mais o problema de latência, garantindo que o ponto âncora esteja associado aos nós de validação mais rápidos. Além disso, a reputação de líderes permite que o Shoal utilize a construção de DAG assíncrona para eliminar timeouts em todos os cenários. Isso permite que o Shoal forneça o que chamamos de atributo de resposta universal, que contém a resposta otimista geralmente necessária.
A tecnologia do Shoal é muito simples, envolve a execução de várias instâncias do protocolo subjacente uma após a outra. Assim, quando instanciamos o Bullshark, obtemos um grupo de "tubarões" que fazem uma corrida de revezamento.
Contexto
Na busca por alto desempenho em redes blockchain, as pessoas têm se preocupado em Gota a complexidade da comunicação. No entanto, esse método não resultou em um aumento significativo na taxa de transferência. Por exemplo, o Hotstuff implementado nas versões iniciais do Diem alcançou apenas 3500 TPS, muito abaixo da meta de 100k+ TPS.
A recente quebra de barreiras advém da compreensão de que a propagação de dados é o principal gargalo baseado no protocolo de líderes, e que pode beneficiar-se da paralelização. O sistema Narwhal separa a propagação de dados da lógica central de consenso, propondo uma arquitetura onde todos os validadores propagam dados simultaneamente, enquanto o componente de consenso apenas ordena uma quantidade reduzida de metadados. O artigo Narwhal reporta uma capacidade de 160.000 TPS.
Aptos apresentou anteriormente o Quorum Store, que é a implementação do Narwhal, separando a propagação de dados do consenso, e é utilizado para escalar o atual protocolo de consenso Jolteon. Jolteon é um protocolo baseado em líder que combina o caminho rápido linear do Tendermint e a mudança de visão no estilo PBFT, podendo reduzir a latência do Hotstuff em 33%. No entanto, os protocolos de consenso baseados em líder não conseguem aproveitar plenamente o potencial de throughput do Narwhal. Apesar de separar a propagação de dados do consenso, à medida que o throughput aumenta, o líder do Hotstuff/Jolteon ainda está limitado.
Portanto, a Aptos decidiu implantar o Bullshark sobre o Narwhal DAG, um protocolo de consenso com zero custo de comunicação. Infelizmente, em comparação com o Jolteon, a estrutura DAG que suporta o Bullshark de alta capacidade traz um custo de latência de 50%.
Este artigo apresenta como o Shoal reduz significativamente a latência do Bullshark.
Contexto do DAG-BFT
Cada vértice no DAG de Narwhal 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 transmitir 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 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.
Sequência total
É possível alcançar consenso sobre a ordem total de todos os vértices no DAG sem custos adicionais de comunicação. Para isso, os validadores em 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 baseados em Narwhal existentes possuem a seguinte estrutura:
Ponto de ancoragem pré-definido: a cada algumas rodadas (, como em duas rodadas ) no Bullshark, haverá um líder previamente determinado, e o ápice do líder é chamado de ponto de ancoragem.
Pontos de ancoragem de ordenação: os validadores decidem de forma independente, mas determinística, quais pontos de ancoragem ordenar e quais ignorar.
ordem da história causal: os validadores processam um a um a sua lista de âncoras ordenadas, e para cada âncora, ordenam todos os vértices anteriores desordenados em sua história causal através de algumas regras determinísticas.
A chave para garantir a segurança é assegurar que, nos passos acima (2), todos os nós de validação honestos criem uma lista de âncoras ordenadas, de modo que todas as listas compartilhem o mesmo prefixo. No Shoal, as seguintes observações são feitas sobre todos os protocolos acima:
Todos os validadores concordam com o primeiro ponto de ancoragem ordenado.
Bullshark latência
A latência do Bullshark depende do número de rodadas entre os pontos âncora ordenados no DAG. Embora a versão de sincronização parcial do Bullshark seja mais prática 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 âncora, e o vértice de cada rodada ímpar é interpretado como um voto. Em situações comuns, são necessárias duas rodadas do DAG para classificar o ponto âncora; no entanto, os vértices na história causal do ponto âncora precisam de mais rodadas para esperar que o ponto âncora seja classificado. Em situações comuns, os vértices na rodada ímpar precisam de três rodadas, enquanto os vértices não âncora na rodada par precisam de quatro rodadas.
Questão 2: latência de casos de falha, a análise de latência acima se aplica a situações 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 pulados ), assim todos os vértices não ordenados nas primeiras rodadas devem esperar que o próximo ponto âncora seja ordenado. Isso pode reduzir significativamente o desempenho da rede de replicação geográfica, especialmente porque o Bullshark usa 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 haja um ponto âncora em cada rodada e reduzindo a latência de todos os vértices não âncora no DAG para três rodadas. Shoal também introduziu um mecanismo de reputação de líder sem custo no DAG, o que faz com que a seleção favoreça 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 linhas de produção anteriores tentaram modificar a lógica central do Bullshark, mas isso parece ser essencialmente impossível.
A reputação do líder é introduzida no DiemBFT e formalizada no Carousel, sendo escolhida dinamicamente com base no desempenho passado dos validadores para futuros líderes, a ideia do âncora no Bullshark (. Embora as divergências na identidade do líder não violem a segurança desses protocolos, no Bullshark, isso pode levar a uma ordenação completamente diferente, o que traz à tona o cerne da questão, ou seja, a escolha dinâmica e determinística do âncora rotativo é necessária para resolver o consenso, e os validadores precisam chegar a um consenso sobre a história ordenada para escolher o futuro âncora.
Como evidência da dificuldade do problema, a implementação do Bullshark, incluindo a implementação atual em ambiente de produção, não suporta essas características.
![Explicação detalhada do framework Shoal: como reduzir a latência do Bullshark no Aptos?])https://img-cdn.gateio.im/webp-social/moments-0b0928cb6240e994c1514c75e080a4b2.webp(
Acordo
Apesar dos desafios acima mencionados, como diz o ditado, a verdade é que a solução se esconde por trás do simples.
No Shoal, dependemos da capacidade de executar cálculos locais no DAG e implementamos a capacidade de armazenar e reinterpretar informações das rodadas anteriores. Com todos os validadores concordando com a visão central do 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, assim como ( a história causal do ponto de ancoragem é utilizada para calcular a reputação do líder.
) linha de montagem
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 é determinada com antecedência pelo mapeamento F. Cada instância ordena uma âncora, o que aciona a transição para a próxima instância.
Inicialmente, o Shoal lançou a primeira instância do Bullshark na primeira rodada do DAG e a executou até determinar o primeiro ponto de âncora ordenado, como na rodada r. Todos os validadores concordaram com este ponto de âncora. Assim, todos os validadores podem concordar de forma definitiva em reinterpretar o DAG a partir da rodada r+1. O Shoal apenas lançou uma nova instância do Bullshark na rodada r+1.
No melhor cenário, isso permite que o Shoal classifique um âncora em cada rodada. O ponto de ancoragem da primeira rodada é classificado pelo primeiro instância. Em seguida, o Shoal inicia uma nova instância na segunda rodada, que por si só tem um ponto de ancoragem, esse âncora é classificado por essa instância, e então, outra nova instância classifica o ponto de ancoragem na terceira rodada, e esse processo continua.
Reputação do Líder
Durante o período de ordenação do Bullshark, a Gota aumenta ao pular pontos de ancoragem. Nesses casos, a tecnologia de pipeline é impotente, pois não é possível iniciar uma nova instância antes da ordenação do ponto de ancoragem da instância anterior. O Shoal assegura que é menos provável que o líder correspondente seja escolhido para lidar com pontos de ancoragem perdidos 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 por meio de um mecanismo de reputação. Os validadores que respondem e participam do protocolo receberão pontuações altas; caso contrário, o nó de validação será atribuído uma pontuação baixa, pois pode estar em colapso, lento ou agindo de má fé.
A sua filosofia é recalcular de forma determinística o mapeamento pré-definido F de cada rodada para o 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 usada para derivar a pontuação.
No Shoal, a linha de montagem e a reputação de liderança podem se combinar naturalmente, uma vez que ambas utilizam a mesma tecnologia central, ou seja, reinterpretar o DAG após alcançar um consenso sobre o primeiro ponto de ancoragem ordenado.
Na verdade, a única diferença é que, após a ordenação dos pontos de ancoragem na r-ésima rodada, os validadores só precisam calcular um novo mapeamento F' a partir da r+1-ésima rodada com base na história causal dos pontos de ancoragem ordenados na r-ésima rodada. Então, os nós de validação começam a usar a função de seleção de pontos de ancoragem atualizada F' para executar uma nova instância do Bullshark a partir da r+1-ésima rodada.
Não há mais latência
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, pois é muito importante configurá-los adequadamente e geralmente requer ajustes dinâmicos, uma vez que depende muito do ambiente ( rede ). Antes de passar para o próximo líder, o protocolo paga a penalização completa do atraso de timeout para o líder com falha. Portanto, a configuração do timeout não pode ser excessivamente conservadora, mas se o tempo de timeout for muito curto, o protocolo pode
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.
10 gostos
Recompensa
10
7
Partilhar
Comentar
0/400
just_here_for_vibes
· 07-27 18:20
Tanta melhoria de desempenho? Vamos lá!
Ver originalResponder0
BridgeNomad
· 07-26 20:35
hmm... a latência melhorada parece boa, mas ainda preciso validar esses vetores de confiança, para ser honesto.
Ver originalResponder0
BearMarketHustler
· 07-26 20:30
Uau, Aptos é bem capaz!
Ver originalResponder0
Whale_Whisperer
· 07-26 20:28
Esta melhoria é incrível! Vamos guardar um pouco de apt.
Ver originalResponder0
CryptoMotivator
· 07-26 20:17
Aptos gogo～latência 80% é realmente feroz
Ver originalResponder0
StakeHouseDirector
· 07-26 20:17
pro ah esta otimização de desempenho é realmente impressionante
Ver originalResponder0
Layer2Observer
· 07-26 20:08
latência aumentou 80% é um pouco hardcore. Aguardando os dados do teste.
O framework Shoal reduziu significativamente a latência Bullshark na cadeia Aptos.
Shoal框架: como Gota a latência do Bullshark na Aptos
Aptos labs resolveu dois importantes problemas abertos no DAG BFT, reduzindo significativamente a latência e eliminando pela primeira vez a necessidade de timeouts em protocolos determinísticos reais. De forma geral, a estrutura Shoal melhorou a latência do Bullshark em 40% em situações sem falhas e em 80% em situações de falha.
Shoal é um framework que aprimora o protocolo de consenso baseado em Narwhal ( por meio de pipeline e reputação de líderes, como DAG-Rider, Tusk, Bullshark ). O pipeline reduz a Gota de ordenação do DAG ao introduzir um ponto âncora a cada rodada, enquanto a reputação de líderes melhora ainda mais o problema de latência, garantindo que o ponto âncora esteja associado aos nós de validação mais rápidos. Além disso, a reputação de líderes permite que o Shoal utilize a construção de DAG assíncrona para eliminar timeouts em todos os cenários. Isso permite que o Shoal forneça o que chamamos de atributo de resposta universal, que contém a resposta otimista geralmente necessária.
A tecnologia do Shoal é muito simples, envolve a execução de várias instâncias do protocolo subjacente uma após a outra. Assim, quando instanciamos o Bullshark, obtemos um grupo de "tubarões" que fazem uma corrida de revezamento.
Contexto
Na busca por alto desempenho em redes blockchain, as pessoas têm se preocupado em Gota a complexidade da comunicação. No entanto, esse método não resultou em um aumento significativo na taxa de transferência. Por exemplo, o Hotstuff implementado nas versões iniciais do Diem alcançou apenas 3500 TPS, muito abaixo da meta de 100k+ TPS.
A recente quebra de barreiras advém da compreensão de que a propagação de dados é o principal gargalo baseado no protocolo de líderes, e que pode beneficiar-se da paralelização. O sistema Narwhal separa a propagação de dados da lógica central de consenso, propondo uma arquitetura onde todos os validadores propagam dados simultaneamente, enquanto o componente de consenso apenas ordena uma quantidade reduzida de metadados. O artigo Narwhal reporta uma capacidade de 160.000 TPS.
Aptos apresentou anteriormente o Quorum Store, que é a implementação do Narwhal, separando a propagação de dados do consenso, e é utilizado para escalar o atual protocolo de consenso Jolteon. Jolteon é um protocolo baseado em líder que combina o caminho rápido linear do Tendermint e a mudança de visão no estilo PBFT, podendo reduzir a latência do Hotstuff em 33%. No entanto, os protocolos de consenso baseados em líder não conseguem aproveitar plenamente o potencial de throughput do Narwhal. Apesar de separar a propagação de dados do consenso, à medida que o throughput aumenta, o líder do Hotstuff/Jolteon ainda está limitado.
Portanto, a Aptos decidiu implantar o Bullshark sobre o Narwhal DAG, um protocolo de consenso com zero custo de comunicação. Infelizmente, em comparação com o Jolteon, a estrutura DAG que suporta o Bullshark de alta capacidade traz um custo de latência de 50%.
Este artigo apresenta como o Shoal reduz significativamente a latência do Bullshark.
Contexto do DAG-BFT
Cada vértice no DAG de Narwhal 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 transmitir 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 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.
Sequência total
É possível alcançar consenso sobre a ordem total de todos os vértices no DAG sem custos adicionais de comunicação. Para isso, os validadores em 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 baseados em Narwhal existentes possuem a seguinte estrutura:
Ponto de ancoragem pré-definido: a cada algumas rodadas (, como em duas rodadas ) no Bullshark, haverá um líder previamente determinado, e o ápice do líder é chamado de ponto de ancoragem.
Pontos de ancoragem de ordenação: os validadores decidem de forma independente, mas determinística, quais pontos de ancoragem ordenar e quais ignorar.
ordem da história causal: os validadores processam um a um a sua lista de âncoras ordenadas, e para cada âncora, ordenam todos os vértices anteriores desordenados em sua história causal através de algumas regras determinísticas.
A chave para garantir a segurança é assegurar que, nos passos acima (2), todos os nós de validação honestos criem uma lista de âncoras ordenadas, de modo que todas as listas compartilhem o mesmo prefixo. No Shoal, as seguintes observações são feitas sobre todos os protocolos acima:
Todos os validadores concordam com o primeiro ponto de ancoragem ordenado.
Bullshark latência
A latência do Bullshark depende do número de rodadas entre os pontos âncora ordenados no DAG. Embora a versão de sincronização parcial do Bullshark seja mais prática 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 âncora, e o vértice de cada rodada ímpar é interpretado como um voto. Em situações comuns, são necessárias duas rodadas do DAG para classificar o ponto âncora; no entanto, os vértices na história causal do ponto âncora precisam de mais rodadas para esperar que o ponto âncora seja classificado. Em situações comuns, os vértices na rodada ímpar precisam de três rodadas, enquanto os vértices não âncora na rodada par precisam de quatro rodadas.
Questão 2: latência de casos de falha, a análise de latência acima se aplica a situações 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 pulados ), assim todos os vértices não ordenados nas primeiras rodadas devem esperar que o próximo ponto âncora seja ordenado. Isso pode reduzir significativamente o desempenho da rede de replicação geográfica, especialmente porque o Bullshark usa 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 haja um ponto âncora em cada rodada e reduzindo a latência de todos os vértices não âncora no DAG para três rodadas. Shoal também introduziu um mecanismo de reputação de líder sem custo no DAG, o que faz com que a seleção favoreça 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 linhas de produção anteriores tentaram modificar a lógica central do Bullshark, mas isso parece ser essencialmente impossível.
A reputação do líder é introduzida no DiemBFT e formalizada no Carousel, sendo escolhida dinamicamente com base no desempenho passado dos validadores para futuros líderes, a ideia do âncora no Bullshark (. Embora as divergências na identidade do líder não violem a segurança desses protocolos, no Bullshark, isso pode levar a uma ordenação completamente diferente, o que traz à tona o cerne da questão, ou seja, a escolha dinâmica e determinística do âncora rotativo é necessária para resolver o consenso, e os validadores precisam chegar a um consenso sobre a história ordenada para escolher o futuro âncora.
Como evidência da dificuldade do problema, a implementação do Bullshark, incluindo a implementação atual em ambiente de produção, não suporta essas características.
![Explicação detalhada do framework Shoal: como reduzir a latência do Bullshark no Aptos?])https://img-cdn.gateio.im/webp-social/moments-0b0928cb6240e994c1514c75e080a4b2.webp(
Acordo
Apesar dos desafios acima mencionados, como diz o ditado, a verdade é que a solução se esconde por trás do simples.
No Shoal, dependemos da capacidade de executar cálculos locais no DAG e implementamos a capacidade de armazenar e reinterpretar informações das rodadas anteriores. Com todos os validadores concordando com a visão central do 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, assim como ( a história causal do ponto de ancoragem é utilizada para calcular a reputação do líder.
) linha de montagem
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 é determinada com antecedência pelo mapeamento F. Cada instância ordena uma âncora, o que aciona a transição para a próxima instância.
Inicialmente, o Shoal lançou a primeira instância do Bullshark na primeira rodada do DAG e a executou até determinar o primeiro ponto de âncora ordenado, como na rodada r. Todos os validadores concordaram com este ponto de âncora. Assim, todos os validadores podem concordar de forma definitiva em reinterpretar o DAG a partir da rodada r+1. O Shoal apenas lançou uma nova instância do Bullshark na rodada r+1.
No melhor cenário, isso permite que o Shoal classifique um âncora em cada rodada. O ponto de ancoragem da primeira rodada é classificado pelo primeiro instância. Em seguida, o Shoal inicia uma nova instância na segunda rodada, que por si só tem um ponto de ancoragem, esse âncora é classificado por essa instância, e então, outra nova instância classifica o ponto de ancoragem na terceira rodada, e esse processo continua.
Reputação do Líder
Durante o período de ordenação do Bullshark, a Gota aumenta ao pular pontos de ancoragem. Nesses casos, a tecnologia de pipeline é impotente, pois não é possível iniciar uma nova instância antes da ordenação do ponto de ancoragem da instância anterior. O Shoal assegura que é menos provável que o líder correspondente seja escolhido para lidar com pontos de ancoragem perdidos 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 por meio de um mecanismo de reputação. Os validadores que respondem e participam do protocolo receberão pontuações altas; caso contrário, o nó de validação será atribuído uma pontuação baixa, pois pode estar em colapso, lento ou agindo de má fé.
A sua filosofia é recalcular de forma determinística o mapeamento pré-definido F de cada rodada para o 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 usada para derivar a pontuação.
No Shoal, a linha de montagem e a reputação de liderança podem se combinar naturalmente, uma vez que ambas utilizam a mesma tecnologia central, ou seja, reinterpretar o DAG após alcançar um consenso sobre o primeiro ponto de ancoragem ordenado.
Na verdade, a única diferença é que, após a ordenação dos pontos de ancoragem na r-ésima rodada, os validadores só precisam calcular um novo mapeamento F' a partir da r+1-ésima rodada com base na história causal dos pontos de ancoragem ordenados na r-ésima rodada. Então, os nós de validação começam a usar a função de seleção de pontos de ancoragem atualizada F' para executar uma nova instância do Bullshark a partir da r+1-ésima rodada.
Não há mais latência
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, pois é muito importante configurá-los adequadamente e geralmente requer ajustes dinâmicos, uma vez que depende muito do ambiente ( rede ). Antes de passar para o próximo líder, o protocolo paga a penalização completa do atraso de timeout para o líder com falha. Portanto, a configuração do timeout não pode ser excessivamente conservadora, mas se o tempo de timeout for muito curto, o protocolo pode