Shoal framework: reduz significativamente a latência do Bullshark na Aptos
Resumo
Aptos labs resolveu dois importantes problemas abertos no DAG BFT, reduzindo significativamente a latência e eliminando pela primeira vez a necessidade de tempo limite em protocolos práticos determinísticos. No geral, melhorou a latência do Bullshark em 40% em caso de ausência de falhas e em 80% em caso de falhas.
Shoal é uma estrutura que melhora qualquer protocolo de consenso baseado em Narwhal através de pipeline e reputação de líderes. O pipeline reduz a latência de ordenação DAG ao introduzir um ponto de ancoragem a cada rodada, enquanto a reputação do líder melhora ainda mais o problema de latência ao garantir que o ponto de ancoragem esteja associado ao nó de validação mais rápido. Além disso, a reputação do líder 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 ofereça a propriedade de resposta universal, que inclui a resposta otimista normalmente necessária.
Esta tecnologia é muito simples, envolvendo a execução em sequência de várias instâncias do protocolo subjacente. Assim, quando instanciamos com Bullshark, obtemos um grupo de "tubarões" que estão a fazer uma corrida de estafetas.
Motivação
Na busca por alto desempenho em redes de blockchain, as pessoas sempre estiveram atentas à redução da complexidade da comunicação. No entanto, essa abordagem não trouxe 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.
As recentes quebras vêm da compreensão de que a propagação de dados é o principal gargalo baseado nos protocolos de liderança, podendo beneficiar-se da paralelização. O sistema Narwhal separa a propagação de dados da lógica de consenso, propondo uma arquitetura onde todos os validadores propagam dados simultaneamente, e o componente de consenso apenas ordena uma pequena quantidade de metadados. O artigo do Narwhal relatou uma capacidade de 160.000 TPS.
Anteriormente, apresentamos o Quorum Store, nossa implementação Narwhal que separa a propagação de dados do consenso, e como usá-lo para escalar o protocolo de consenso atual Jolteon. Jolteon é um protocolo baseado em líder, que combina o caminho linear rápido do Tendermint e as mudanças de visão estilo PBFT, reduzindo 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, com o aumento do throughput, o líder do Hotstuff/Jolteon ainda está limitado.
Portanto, decidimos implantar o Bullshark sobre o Narwhal DAG, um protocolo de consenso sem custo de comunicação. Infelizmente, em comparação com o Jolteon, a estrutura DAG que suporta o Bullshark com alta taxa de transferência traz um custo de latência de 50%.
Este artigo apresenta como o Shoal consegue reduzir significativamente a latência do Bullshark.
Contexto DAG-BFT
Cada vértice no Narwhal DAG está associado a um número de rodada. Para entrar na rodada r, um 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 propriedade chave do DAG não é ambígua: se dois nós de validação têm o mesmo vértice v em suas visões locais do DAG, então eles têm a mesma história causal de v.
Prefácio
É 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 Âncora: a cada algumas rodadas há um líder pré-determinado, o vértice do líder é chamado de ponto de âncora;
Pontos de ancoragem do pedido: os validadores decidem de forma independente, mas determinística, quais pontos de ancoragem solicitar e quais pular;
Encomendar a história causal: os validadores processam um a um a lista de âncoras ordenadas e ordenam todos os vértices não ordenados anteriores na história causal de cada âncora.
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 ordenadas, 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 âncora ordenado.
Bullshark latência
A latência do Bullshark depende do número de rodadas entre os âncoras ordenados no DAG. Embora a versão síncrona do Bullshark seja mais prática e 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 âncora, enquanto os vértices da rodada ímpar são interpretados como votos. Em casos comuns, são necessárias duas rodadas do DAG para ordenar os pontos de âncora, no entanto, os vértices na história causal dos pontos de âncora precisam de mais rodadas para que os pontos de âncora sejam ordenados. Em casos comuns, os vértices da rodada ímpar precisam de três rodadas, enquanto os vértices não âncora da 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 falha, por outro lado, se o líder de uma rodada não conseguir difundir rapidamente o ponto âncora, não será possível ordenar o ponto âncora (, portanto será pulado ), assim todos os vértices não ordenados nas rodadas anteriores devem aguardar o próximo ponto âncora ser ordenado. Isso reduzirá significativamente o desempenho da rede de replicação geográfica, especialmente porque o tempo limite Bullshark é usado para aguardar o 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 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 favoreça líderes rápidos.
Desafio
No contexto do protocolo DAG, o pipeline e a reputação do líder são considerados problemas difíceis, pelas seguintes razões:
Tentativas anteriores de modificar a lógica central do Bullshark pareciam essencialmente impossíveis.
A reputação do líder é introduzida no DiemBFT e formalizada no Carousel, sendo selecionada dinamicamente com base no desempenho passado dos validadores para futuros líderes, a ideia dos âncoras no Bullshark (. Embora haja divergências na identidade do líder, isso não compromete a segurança dos protocolos, mas no Bullshark, pode levar a ordenações completamente diferentes, levantando o cerne da questão, que é a seleção dinâmica e determinística das âncoras rotativas, que é necessária para resolver o consenso, e os validadores precisam concordar sobre a história ordenada para escolher as âncoras futuras.
Como evidência da dificuldade do problema, notamos que a implementação do Bullshark, incluindo a implementação atualmente no ambiente de produção, não suporta essas características.
Protocolo
Apesar dos desafios mencionados, como diz o ditado, a verdade é que a solução está escondida por trás do simples.
No Shoal, dependemos da capacidade de executar cálculos locais sobre o DAG e implementamos a capacidade de salvar e reinterpretar as informações das rodadas anteriores. Com a percepção central de que todos os validadores concordam com o primeiro ponto âncora ordenado, o Shoal combina sequencialmente várias instâncias de Bullshark para processá-las em pipeline, fazendo com que ) o primeiro ponto âncora ordenado seja o ponto de mudança das instâncias, e ( a história causal do ponto âncora seja utilizada para calcular a reputação do líder.
![Explicação detalhada do Shoal Framework: como reduzir a latência do Bullshark na Aptos?])https://img-cdn.gateio.im/webp-social/moments-0b0928cb6240e994c1514c75e080a4b2.webp(
Linha de Produção
V que mapeia as rodadas para os líderes. O Shoal executa instâncias do Bullshark uma após a outra, de modo que para cada instância, o âncora é previamente determinado pelo mapeamento F. Cada instância encomenda um âncora, o que aciona a mudança para a próxima instância.
Inicialmente, o Shoal iniciou 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 concordam com este ponto âncora. Assim, todos os validadores podem concordar de forma confiável em reinterpretar o DAG a partir da rodada r+1. O Shoal simplesmente iniciou uma nova instância do Bullshark na rodada r+1.
No melhor cenário, isso permite que o Shoal encomende um âncora em cada rodada. Os pontos de âncora da primeira rodada são ordenados pelo primeiro instância. Em seguida, o Shoal inicia uma nova instância na segunda rodada, que por sua vez tem um ponto de âncora, esse âncora é ordenado por essa instância, e então, outra nova instância encomenda pontos de âncora na terceira rodada, e então o processo continua.
![Explicação detalhada do framework Shoal: como reduzir a latência do Bullshark na Aptos?])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 pontos de âncora. Nesse caso, a técnica de pipeline não pode ajudar, pois uma nova instância não pode ser iniciada antes que a instância anterior ordene os pontos de âncora. O Shoal assegura que é menos provável que os líderes correspondentes sejam escolhidos para lidar com os pontos de âncora perdidos, 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 de um mecanismo de reputação. Os validadores que respondem e participam do protocolo receberão altas pontuações, caso contrário, os nós de validação receberão baixas pontuações, pois podem estar em falha, lentos ou agindo mal.
A sua filosofia é recalcular de forma determinística a mapeação predefinida F do turno ao líder sempre que a pontuação é atualizada, favorecendo os líderes com pontuações mais altas. Para que os validadores cheguem a um consenso sobre a nova mapeação, eles devem concordar 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 combinar-se naturalmente, pois ambas utilizam a mesma tecnologia central, ou seja, reinterpretar o DAG após alcançar consenso sobre o primeiro ponto âncora ordenado.
Na verdade, a única diferença é que, após ordenar os pontos âncora 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 dos pontos âncora ordenados na r-ésima rodada. Em seguida, os nós de validação começam a usar a função de seleção de pontos âncora atualizada F' para executar uma nova instância do Bullshark a partir da r+1-ésima rodada.
![Explicação detalhada do Shoal Framework: Como reduzir a latência do Bullshark na Aptos?])https://img-cdn.gateio.im/webp-social/moments-9f789cb669f6fcc244ea7ff7648e48b4.webp(
Sem mais tempos limite
O tempo limite desempenha um papel crucial em todas as implementações BFT determinísticas baseadas em líderes. No entanto, a complexidade que 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 tempo de espera também aumentará significativamente a latência, pois é muito importante configurá-los adequadamente e geralmente requer ajustes dinâmicos, pois depende muito do ambiente ) da rede (. Antes de mudar para o próximo líder, o protocolo pagará a penalidade total de latência do tempo de espera para um líder com falha. Portanto, a configuração do tempo de espera não pode ser muito conservadora, mas se o tempo de espera for muito curto, o protocolo pode ignorar bons líderes. Por exemplo, observamos que, em situações de alta carga, os líderes no Jolteon/Hotstuff ficam sobrecarregados e o tempo de espera já expirou antes que eles possam avançar.
Esta página pode conter conteúdo de terceiros, que é fornecido apenas para fins informativos (não para representações/garantias) e não deve ser considerada como um endosso de suas opiniões pela Gate nem como aconselhamento financeiro ou profissional. Consulte a Isenção de responsabilidade para obter detalhes.
7 Curtidas
Recompensa
7
5
Compartilhar
Comentário
0/400
SchrodingersFOMO
· 08-05 13:55
latência caiu tanto bull bull
Ver originalResponder0
SchroedingerMiner
· 08-05 12:20
Esta velocidade sobe mais rápido do que a temperatura do meu equipamento de mineração.
Ver originalResponder0
MEVSandwich
· 08-03 18:14
latência caiu tanto, sinto que vai Até à lua
Ver originalResponder0
MetaMisfit
· 08-03 17:54
Aguardando ansiosamente pela revolução do Aptos... Expectativa
O framework Shoal melhora significativamente o desempenho do Bullshark na Aptos, com uma Gota de 40%-80%.
Shoal framework: reduz significativamente a latência do Bullshark na Aptos
Resumo
Aptos labs resolveu dois importantes problemas abertos no DAG BFT, reduzindo significativamente a latência e eliminando pela primeira vez a necessidade de tempo limite em protocolos práticos determinísticos. No geral, melhorou a latência do Bullshark em 40% em caso de ausência de falhas e em 80% em caso de falhas.
Shoal é uma estrutura que melhora qualquer protocolo de consenso baseado em Narwhal através de pipeline e reputação de líderes. O pipeline reduz a latência de ordenação DAG ao introduzir um ponto de ancoragem a cada rodada, enquanto a reputação do líder melhora ainda mais o problema de latência ao garantir que o ponto de ancoragem esteja associado ao nó de validação mais rápido. Além disso, a reputação do líder 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 ofereça a propriedade de resposta universal, que inclui a resposta otimista normalmente necessária.
Esta tecnologia é muito simples, envolvendo a execução em sequência de várias instâncias do protocolo subjacente. Assim, quando instanciamos com Bullshark, obtemos um grupo de "tubarões" que estão a fazer uma corrida de estafetas.
Motivação
Na busca por alto desempenho em redes de blockchain, as pessoas sempre estiveram atentas à redução da complexidade da comunicação. No entanto, essa abordagem não trouxe 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.
As recentes quebras vêm da compreensão de que a propagação de dados é o principal gargalo baseado nos protocolos de liderança, podendo beneficiar-se da paralelização. O sistema Narwhal separa a propagação de dados da lógica de consenso, propondo uma arquitetura onde todos os validadores propagam dados simultaneamente, e o componente de consenso apenas ordena uma pequena quantidade de metadados. O artigo do Narwhal relatou uma capacidade de 160.000 TPS.
Anteriormente, apresentamos o Quorum Store, nossa implementação Narwhal que separa a propagação de dados do consenso, e como usá-lo para escalar o protocolo de consenso atual Jolteon. Jolteon é um protocolo baseado em líder, que combina o caminho linear rápido do Tendermint e as mudanças de visão estilo PBFT, reduzindo 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, com o aumento do throughput, o líder do Hotstuff/Jolteon ainda está limitado.
Portanto, decidimos implantar o Bullshark sobre o Narwhal DAG, um protocolo de consenso sem custo de comunicação. Infelizmente, em comparação com o Jolteon, a estrutura DAG que suporta o Bullshark com alta taxa de transferência traz um custo de latência de 50%.
Este artigo apresenta como o Shoal consegue reduzir significativamente a latência do Bullshark.
Contexto DAG-BFT
Cada vértice no Narwhal DAG está associado a um número de rodada. Para entrar na rodada r, um 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 propriedade chave do DAG não é ambígua: se dois nós de validação têm o mesmo vértice v em suas visões locais do DAG, então eles têm a mesma história causal de v.
Prefácio
É 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 Âncora: a cada algumas rodadas há um líder pré-determinado, o vértice do líder é chamado de ponto de âncora;
Pontos de ancoragem do pedido: os validadores decidem de forma independente, mas determinística, quais pontos de ancoragem solicitar e quais pular;
Encomendar a história causal: os validadores processam um a um a lista de âncoras ordenadas e ordenam todos os vértices não ordenados anteriores na história causal de cada âncora.
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 ordenadas, 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 âncora ordenado.
Bullshark latência
A latência do Bullshark depende do número de rodadas entre os âncoras ordenados no DAG. Embora a versão síncrona do Bullshark seja mais prática e 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 âncora, enquanto os vértices da rodada ímpar são interpretados como votos. Em casos comuns, são necessárias duas rodadas do DAG para ordenar os pontos de âncora, no entanto, os vértices na história causal dos pontos de âncora precisam de mais rodadas para que os pontos de âncora sejam ordenados. Em casos comuns, os vértices da rodada ímpar precisam de três rodadas, enquanto os vértices não âncora da 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 falha, por outro lado, se o líder de uma rodada não conseguir difundir rapidamente o ponto âncora, não será possível ordenar o ponto âncora (, portanto será pulado ), assim todos os vértices não ordenados nas rodadas anteriores devem aguardar o próximo ponto âncora ser ordenado. Isso reduzirá significativamente o desempenho da rede de replicação geográfica, especialmente porque o tempo limite Bullshark é usado para aguardar o 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 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 favoreça líderes rápidos.
Desafio
No contexto do protocolo DAG, o pipeline e a reputação do líder são considerados problemas difíceis, pelas seguintes razões:
Tentativas anteriores de modificar a lógica central do Bullshark pareciam essencialmente impossíveis.
A reputação do líder é introduzida no DiemBFT e formalizada no Carousel, sendo selecionada dinamicamente com base no desempenho passado dos validadores para futuros líderes, a ideia dos âncoras no Bullshark (. Embora haja divergências na identidade do líder, isso não compromete a segurança dos protocolos, mas no Bullshark, pode levar a ordenações completamente diferentes, levantando o cerne da questão, que é a seleção dinâmica e determinística das âncoras rotativas, que é necessária para resolver o consenso, e os validadores precisam concordar sobre a história ordenada para escolher as âncoras futuras.
Como evidência da dificuldade do problema, notamos que a implementação do Bullshark, incluindo a implementação atualmente no ambiente de produção, não suporta essas características.
Protocolo
Apesar dos desafios mencionados, como diz o ditado, a verdade é que a solução está escondida por trás do simples.
No Shoal, dependemos da capacidade de executar cálculos locais sobre o DAG e implementamos a capacidade de salvar e reinterpretar as informações das rodadas anteriores. Com a percepção central de que todos os validadores concordam com o primeiro ponto âncora ordenado, o Shoal combina sequencialmente várias instâncias de Bullshark para processá-las em pipeline, fazendo com que ) o primeiro ponto âncora ordenado seja o ponto de mudança das instâncias, e ( a história causal do ponto âncora seja utilizada para calcular a reputação do líder.
![Explicação detalhada do Shoal Framework: como reduzir a latência do Bullshark na Aptos?])https://img-cdn.gateio.im/webp-social/moments-0b0928cb6240e994c1514c75e080a4b2.webp(
Linha de Produção
V que mapeia as rodadas para os líderes. O Shoal executa instâncias do Bullshark uma após a outra, de modo que para cada instância, o âncora é previamente determinado pelo mapeamento F. Cada instância encomenda um âncora, o que aciona a mudança para a próxima instância.
Inicialmente, o Shoal iniciou 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 concordam com este ponto âncora. Assim, todos os validadores podem concordar de forma confiável em reinterpretar o DAG a partir da rodada r+1. O Shoal simplesmente iniciou uma nova instância do Bullshark na rodada r+1.
No melhor cenário, isso permite que o Shoal encomende um âncora em cada rodada. Os pontos de âncora da primeira rodada são ordenados pelo primeiro instância. Em seguida, o Shoal inicia uma nova instância na segunda rodada, que por sua vez tem um ponto de âncora, esse âncora é ordenado por essa instância, e então, outra nova instância encomenda pontos de âncora na terceira rodada, e então o processo continua.
![Explicação detalhada do framework Shoal: como reduzir a latência do Bullshark na Aptos?])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 pontos de âncora. Nesse caso, a técnica de pipeline não pode ajudar, pois uma nova instância não pode ser iniciada antes que a instância anterior ordene os pontos de âncora. O Shoal assegura que é menos provável que os líderes correspondentes sejam escolhidos para lidar com os pontos de âncora perdidos, 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 de um mecanismo de reputação. Os validadores que respondem e participam do protocolo receberão altas pontuações, caso contrário, os nós de validação receberão baixas pontuações, pois podem estar em falha, lentos ou agindo mal.
A sua filosofia é recalcular de forma determinística a mapeação predefinida F do turno ao líder sempre que a pontuação é atualizada, favorecendo os líderes com pontuações mais altas. Para que os validadores cheguem a um consenso sobre a nova mapeação, eles devem concordar 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 combinar-se naturalmente, pois ambas utilizam a mesma tecnologia central, ou seja, reinterpretar o DAG após alcançar consenso sobre o primeiro ponto âncora ordenado.
Na verdade, a única diferença é que, após ordenar os pontos âncora 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 dos pontos âncora ordenados na r-ésima rodada. Em seguida, os nós de validação começam a usar a função de seleção de pontos âncora atualizada F' para executar uma nova instância do Bullshark a partir da r+1-ésima rodada.
![Explicação detalhada do Shoal Framework: Como reduzir a latência do Bullshark na Aptos?])https://img-cdn.gateio.im/webp-social/moments-9f789cb669f6fcc244ea7ff7648e48b4.webp(
Sem mais tempos limite
O tempo limite desempenha um papel crucial em todas as implementações BFT determinísticas baseadas em líderes. No entanto, a complexidade que 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 tempo de espera também aumentará significativamente a latência, pois é muito importante configurá-los adequadamente e geralmente requer ajustes dinâmicos, pois depende muito do ambiente ) da rede (. Antes de mudar para o próximo líder, o protocolo pagará a penalidade total de latência do tempo de espera para um líder com falha. Portanto, a configuração do tempo de espera não pode ser muito conservadora, mas se o tempo de espera for muito curto, o protocolo pode ignorar bons líderes. Por exemplo, observamos que, em situações de alta carga, os líderes no Jolteon/Hotstuff ficam sobrecarregados e o tempo de espera já expirou antes que eles possam avançar.
infeliz