Estrutura Shoal: Melhoria da latência do consenso Bullshark no Aptos
Aptos Labs resolveu recentemente dois problemas abertos importantes no DAG BFT, reduzindo significativamente a latência e eliminando pela primeira vez a necessidade de timeouts em protocolos assíncronos determinísticos. No geral, melhorou a latência do Bullshark em 40% em situações sem falhas e em 80% em situações com falhas.
Shoal é um framework que melhora o protocolo de consenso baseado em Narwhal ( através de processamento em pipeline e um mecanismo de reputação do líder, como DAG-Rider, Tusk, Bullshark ). O processamento em pipeline reduz a latência de ordenação do DAG ao introduzir um ponto de ancoragem a cada rodada, enquanto o mecanismo de reputação do líder melhora ainda mais o problema de latência ao garantir que os pontos de ancoragem estejam associados aos nós de validação mais rápidos. Além disso, a reputação do líder permite que Shoal utilize a construção de DAG assíncrona para eliminar os timeouts em todos os cenários. Isso permite que Shoal ofereça uma propriedade chamada resposta universal, que inclui a resposta otimista normalmente necessária.
A tecnologia do Shoal é relativamente simples, envolvendo a execução de múltiplas instâncias do protocolo subjacente em sequência. Quando instanciamos com Bullshark, obtemos um grupo de "tubarões" em uma corrida de revezamento.
Contexto e Motivação
Na busca por alto desempenho em redes de blockchain, as pessoas sempre se concentraram na redução da complexidade de 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 últimas inovações resultam do reconhecimento de que a propagação de dados é o principal gargalo baseado no consenso dos líderes, podendo beneficiar-se da paralelização. O sistema Narwhal separa a propagação de dados da lógica central de consenso, propondo uma arquitetura em que todos os validadores propagam dados simultaneamente, enquanto o componente de consenso apenas ordena uma pequena quantidade de metadados. O artigo do Narwhal reportou uma capacidade de 160.000 TPS.
No artigo anterior, apresentamos o Quorum Store. O Narwhal implementa a separação da propagação de dados e do consenso, bem como como utilizá-lo para escalar o atual protocolo de consenso Jolteon. Jolteon é um protocolo baseado em líder, que combina o caminho rápido linear do Tendermint com as mudanças de vista 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. Embora a propagação de dados e o consenso estejam separados, à medida que o throughput aumenta, o líder do Hotstuff/Jolteon ainda enfrenta limitações.
Assim, decidimos implementar o Bullshark sobre o Narwhal DAG, que é um protocolo de consenso com zero custos 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 apresentará como o Shoal reduz significativamente a latência do Bullshark.
Contexto do DAG-BFT
Cada vértice no DAG do Narwhal está associado a uma rodada. Para entrar na rodada r, os validadores devem primeiro obter n-f vértices pertencentes à 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 vistas locais do DAG em qualquer ponto no tempo.
Uma propriedade chave do DAG é que 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.
Ordem Geral
É possível alcançar 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 em Narwhal apresentam a seguinte estrutura:
Ponto âncora: a cada algumas rodadas haverá um líder pré-determinado, o pico do líder é chamado de ponto âncora.
Classificação de âncoras: os validadores decidem de forma independente, mas determinística, quais âncoras classificar e quais âncoras ignorar.
Ordenação histórica causal: os validadores processam um a um a lista de âncoras ordenadas e ordenam todos os vértices anteriores desordenados 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, para que todas as listas compartilhem o mesmo prefixo. No Shoal, fazemos as seguintes observações sobre todos os protocolos mencionados 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 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.
Questão 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 os pontos de ancoragem; no entanto, os vértices na história causal dos pontos de ancoragem precisam de mais rodadas para que os pontos de ancoragem sejam ordenados. 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.
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 transmitir os pontos âncora rapidamente o suficiente, os pontos âncora não poderão ser ordenados (, portanto, serão pulados ), e todos os vértices não ordenados nas primeiras rodadas devem esperar que o próximo ponto âncora seja ordenado. Isso reduzirá significativamente o desempenho da rede de replicação geográfica, especialmente porque o Bullshark usa tempo limite para esperar pelo líder.
Estrutura Shoal
Shoal resolveu esses dois problemas de latência, aprimorando o Bullshark( ou qualquer outro protocolo BFT baseado em Narwhal) através de processamento em pipeline, permitindo que haja um ponto de ancoragem 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 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 processamento em pipeline e a reputação do líder são considerados problemas difíceis, pelos seguintes motivos:
As tentativas anteriores de processamento em linha modificaram 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 escolhidos dinamicamente futuros líderes com base no desempenho passado dos validadores, 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 seleção dinâmica e determinística do âncora do ciclo é necessária para resolver o consenso, e os validadores precisam chegar a um consenso sobre a história ordenada para escolher 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.
( protocolo
Apesar dos desafios mencionados, a solução está escondida na simplicidade. No Shoal, confiamos na capacidade de realizar cálculos locais sobre o DAG e implementamos a capacidade de salvar e reinterpretar as informações das rodadas anteriores. Com todos os validadores concordando com a percepção central do primeiro ponto de ancoragem ordenado, o Shoal combina sequencialmente várias instâncias de Bullshark para processá-las em pipeline, tornando ) o primeiro ponto de ancoragem ordenado o ponto de mudança das instâncias, bem como ### a história causal do ponto de ancoragem usada para calcular a reputação do líder.
( processamento em linha
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, a âncora é previamente determinada pelo mapeamento F. Cada instância ordena uma âncora, o que aciona a transição 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 concordaram com esse ponto âncora. Portanto, todos os validadores podem concordar de forma confiável em reinterpretar o DAG a partir da rodada r+1. O Shoal apenas iniciou uma nova instância do Bullshark na rodada r+1.
No melhor cenário, isso permite que o Shoal ordene um âncora em cada rodada. O ponto de âncora da primeira rodada é ordenado pelo primeiro instância. Em seguida, o Shoal inicia uma nova instância na segunda rodada, que por si só tem um ponto de âncora, que é ordenado por essa instância, e então, outra nova instância ordena o ponto de âncora na terceira rodada, e o processo continua.
Durante a ordenação Bullshark, ao pular pontos âncora, a latência aumenta. Neste caso, a técnica de processamento em pipeline é incapaz, pois não é possível iniciar uma nova instância antes do ponto âncora da instância anterior ser ordenado. O Shoal garante que seja menos provável que líderes correspondentes sejam escolhidos para tratar pontos âncora perdidos no futuro, atribuindo uma pontuação a cada nó de validação com base no histórico de atividades recentes de cada nó de validação por meio 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 com problemas, lentos ou agir de forma maliciosa.
A sua ideia é recalcular de forma determinística o mapeamento predefinido F do round 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, o processamento em pipeline e a reputação do líder podem se combinar naturalmente, uma vez que ambos utilizam a mesma tecnologia central, ou seja, reinterpretar o DAG após chegar a um consenso sobre o primeiro ponto âncora ordenado.
Na verdade, a única diferença é que, após classificar os pontos de ancoragem na r-ésima rodada, o validador só precisa 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. Depois, 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.
O tempo limite desempenha um papel crucial em todas as implementações BFT determinísticas baseadas em líderes. 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 tempo de espera também aumentará significativamente a latência, pois é muito importante configurá-los adequadamente e geralmente requer ajustes dinâmicos, uma vez que depende fortemente do ambiente ### rede (. Antes de transferir para o próximo líder, o protocolo pagará a penalização completa do tempo de espera para líderes com falhas. Portanto, as configurações de tempo de espera não podem ser excessivamente conservadoras, mas se o tempo de espera for muito curto, o protocolo pode pular bons líderes. Por exemplo, observamos que, em situações de alta carga, os líderes em Jolteon/Hotstuff ficam sobrecarregados e o tempo de espera já havia expirado antes que eles pudessem avançar.
Infelizmente, o protocolo baseado em líderes ) como o Hotstuff
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.
9 gostos
Recompensa
9
6
Republicar
Partilhar
Comentar
0/400
SchrodingerProfit
· 4h atrás
Esta agora a aptos vai até à lua
Ver originalResponder0
CodeAuditQueen
· 11h atrás
A otimização de algoritmos complexos também apresenta risco de reentrada de poder de computação. Espero que não haja problemas.
Ver originalResponder0
metaverse_hermit
· 11h atrás
aptos ainda está vivo tql
Ver originalResponder0
ReverseTradingGuru
· 11h atrás
Outra vez, outra vez, outra vez, atualizado! bull beer
Ver originalResponder0
DeadTrades_Walking
· 11h atrás
A melhoria da eficiência está boa, não se esqueça de enviar a pontuação.
O quadro Shoal melhora a eficiência do consenso do Aptos: a latência do Bullshark é reduzida em 40-80%.
Estrutura Shoal: Melhoria da latência do consenso Bullshark no Aptos
Aptos Labs resolveu recentemente dois problemas abertos importantes no DAG BFT, reduzindo significativamente a latência e eliminando pela primeira vez a necessidade de timeouts em protocolos assíncronos determinísticos. No geral, melhorou a latência do Bullshark em 40% em situações sem falhas e em 80% em situações com falhas.
Shoal é um framework que melhora o protocolo de consenso baseado em Narwhal ( através de processamento em pipeline e um mecanismo de reputação do líder, como DAG-Rider, Tusk, Bullshark ). O processamento em pipeline reduz a latência de ordenação do DAG ao introduzir um ponto de ancoragem a cada rodada, enquanto o mecanismo de reputação do líder melhora ainda mais o problema de latência ao garantir que os pontos de ancoragem estejam associados aos nós de validação mais rápidos. Além disso, a reputação do líder permite que Shoal utilize a construção de DAG assíncrona para eliminar os timeouts em todos os cenários. Isso permite que Shoal ofereça uma propriedade chamada resposta universal, que inclui a resposta otimista normalmente necessária.
A tecnologia do Shoal é relativamente simples, envolvendo a execução de múltiplas instâncias do protocolo subjacente em sequência. Quando instanciamos com Bullshark, obtemos um grupo de "tubarões" em uma corrida de revezamento.
Contexto e Motivação
Na busca por alto desempenho em redes de blockchain, as pessoas sempre se concentraram na redução da complexidade de 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 últimas inovações resultam do reconhecimento de que a propagação de dados é o principal gargalo baseado no consenso dos líderes, podendo beneficiar-se da paralelização. O sistema Narwhal separa a propagação de dados da lógica central de consenso, propondo uma arquitetura em que todos os validadores propagam dados simultaneamente, enquanto o componente de consenso apenas ordena uma pequena quantidade de metadados. O artigo do Narwhal reportou uma capacidade de 160.000 TPS.
No artigo anterior, apresentamos o Quorum Store. O Narwhal implementa a separação da propagação de dados e do consenso, bem como como utilizá-lo para escalar o atual protocolo de consenso Jolteon. Jolteon é um protocolo baseado em líder, que combina o caminho rápido linear do Tendermint com as mudanças de vista 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. Embora a propagação de dados e o consenso estejam separados, à medida que o throughput aumenta, o líder do Hotstuff/Jolteon ainda enfrenta limitações.
Assim, decidimos implementar o Bullshark sobre o Narwhal DAG, que é um protocolo de consenso com zero custos 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 apresentará como o Shoal reduz significativamente a latência do Bullshark.
Contexto do DAG-BFT
Cada vértice no DAG do Narwhal está associado a uma rodada. Para entrar na rodada r, os validadores devem primeiro obter n-f vértices pertencentes à 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 vistas locais do DAG em qualquer ponto no tempo.
Uma propriedade chave do DAG é que 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.
Ordem Geral
É possível alcançar 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 em Narwhal apresentam a seguinte estrutura:
Ponto âncora: a cada algumas rodadas haverá um líder pré-determinado, o pico do líder é chamado de ponto âncora.
Classificação de âncoras: os validadores decidem de forma independente, mas determinística, quais âncoras classificar e quais âncoras ignorar.
Ordenação histórica causal: os validadores processam um a um a lista de âncoras ordenadas e ordenam todos os vértices anteriores desordenados 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, para que todas as listas compartilhem o mesmo prefixo. No Shoal, fazemos as seguintes observações sobre todos os protocolos mencionados 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 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.
Questão 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 os pontos de ancoragem; no entanto, os vértices na história causal dos pontos de ancoragem precisam de mais rodadas para que os pontos de ancoragem sejam ordenados. 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.
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 transmitir os pontos âncora rapidamente o suficiente, os pontos âncora não poderão ser ordenados (, portanto, serão pulados ), e todos os vértices não ordenados nas primeiras rodadas devem esperar que o próximo ponto âncora seja ordenado. Isso reduzirá significativamente o desempenho da rede de replicação geográfica, especialmente porque o Bullshark usa tempo limite para esperar pelo líder.
Estrutura Shoal
Shoal resolveu esses dois problemas de latência, aprimorando o Bullshark( ou qualquer outro protocolo BFT baseado em Narwhal) através de processamento em pipeline, permitindo que haja um ponto de ancoragem 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 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 processamento em pipeline e a reputação do líder são considerados problemas difíceis, pelos seguintes motivos:
As tentativas anteriores de processamento em linha modificaram 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 escolhidos dinamicamente futuros líderes com base no desempenho passado dos validadores, 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 seleção dinâmica e determinística do âncora do ciclo é necessária para resolver o consenso, e os validadores precisam chegar a um consenso sobre a história ordenada para escolher 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.
( protocolo
Apesar dos desafios mencionados, a solução está escondida na simplicidade. No Shoal, confiamos na capacidade de realizar cálculos locais sobre o DAG e implementamos a capacidade de salvar e reinterpretar as informações das rodadas anteriores. Com todos os validadores concordando com a percepção central do primeiro ponto de ancoragem ordenado, o Shoal combina sequencialmente várias instâncias de Bullshark para processá-las em pipeline, tornando ) o primeiro ponto de ancoragem ordenado o ponto de mudança das instâncias, bem como ### a história causal do ponto de ancoragem usada para calcular a reputação do líder.
( processamento em linha
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, a âncora é previamente determinada pelo mapeamento F. Cada instância ordena uma âncora, o que aciona a transição 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 concordaram com esse ponto âncora. Portanto, todos os validadores podem concordar de forma confiável em reinterpretar o DAG a partir da rodada r+1. O Shoal apenas iniciou uma nova instância do Bullshark na rodada r+1.
No melhor cenário, isso permite que o Shoal ordene um âncora em cada rodada. O ponto de âncora da primeira rodada é ordenado pelo primeiro instância. Em seguida, o Shoal inicia uma nova instância na segunda rodada, que por si só tem um ponto de âncora, que é ordenado por essa instância, e então, outra nova instância ordena o ponto de âncora na terceira rodada, e o processo continua.
![万字详解Shoal框架：如何减少Aptos上的Bullshark latência？])https://img-cdn.gateio.im/webp-social/moments-0b0928cb6240e994c1514c75e080a4b2.webp(
) reputação do líder
Durante a ordenação Bullshark, ao pular pontos âncora, a latência aumenta. Neste caso, a técnica de processamento em pipeline é incapaz, pois não é possível iniciar uma nova instância antes do ponto âncora da instância anterior ser ordenado. O Shoal garante que seja menos provável que líderes correspondentes sejam escolhidos para tratar pontos âncora perdidos no futuro, atribuindo uma pontuação a cada nó de validação com base no histórico de atividades recentes de cada nó de validação por meio 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 com problemas, lentos ou agir de forma maliciosa.
A sua ideia é recalcular de forma determinística o mapeamento predefinido F do round 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, o processamento em pipeline e a reputação do líder podem se combinar naturalmente, uma vez que ambos utilizam a mesma tecnologia central, ou seja, reinterpretar o DAG após chegar a um consenso sobre o primeiro ponto âncora ordenado.
Na verdade, a única diferença é que, após classificar os pontos de ancoragem na r-ésima rodada, o validador só precisa 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. Depois, 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.
![万字详解Shoal框架：如何减少Aptos上的Bullshark latência？]###https://img-cdn.gateio.im/webp-social/moments-859e732e16c3eee0e2c93422474debc2.webp(
) Não há mais tempo de espera
O tempo limite desempenha um papel crucial em todas as implementações BFT determinísticas baseadas em líderes. 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 tempo de espera também aumentará significativamente a latência, pois é muito importante configurá-los adequadamente e geralmente requer ajustes dinâmicos, uma vez que depende fortemente do ambiente ### rede (. Antes de transferir para o próximo líder, o protocolo pagará a penalização completa do tempo de espera para líderes com falhas. Portanto, as configurações de tempo de espera não podem ser excessivamente conservadoras, mas se o tempo de espera for muito curto, o protocolo pode pular bons líderes. Por exemplo, observamos que, em situações de alta carga, os líderes em Jolteon/Hotstuff ficam sobrecarregados e o tempo de espera já havia expirado antes que eles pudessem avançar.
Infelizmente, o protocolo baseado em líderes ) como o Hotstuff