Estrutura Shoal: Como Gota a latência do Bullshark na Aptos?
Visão geral
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 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 com falhas.
Shoal é uma estrutura que melhora qualquer protocolo de consenso baseado em Narwhal ( como DAG-Rider, Tusk, Bullshark ) através de pipeline e reputação do líder. O pipeline reduz a latência na ordenação do DAG ao introduzir um ponto de âncora em cada rodada, enquanto a reputação do líder melhora ainda mais o problema da latência assegurando que o ponto de âncora esteja associado aos nós de validação mais rápidos. Além disso, a reputação do líder permite que Shoal aproveite a construção de DAG assíncrona para eliminar os tempos limite em todos os cenários. Isso permite que Shoal ofereça propriedades de resposta universal, incluindo a resposta otimista normalmente necessária.
Esta tecnologia é muito simples, envolvendo a execução sequencial de várias instâncias do protocolo subjacente. Assim, quando instanciamos com Bullshark, obtemos um grupo de "tubarões" que estão participando de uma corrida de revezamento.
Motivação
Na busca por alto desempenho em redes de blockchain, tem-se prestado atenção à Gota da 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 atingiu apenas 3500 TPS, muito abaixo da meta de 100k+ TPS.
Recent breakthroughs stem from the realization that data propagation is the main bottleneck based on leader protocols, which can benefit from parallelization. The Narwhal system separates data propagation from core consensus logic, proposing an architecture where all validators propagate data simultaneously, while the consensus component only orders a small amount of metadata. The Narwhal paper reported a throughput of 160,000 TPS.
Anteriormente, apresentamos o Quorum Store, que separa a propagação de dados do consenso, e como usá-lo para escalar o atual protocolo de consenso Jolteon. Jolteon é um protocolo baseado em líderes, que combina o caminho rápido linear do Tendermint e a mudança de vista no estilo PBFT, capaz de reduzir a latência do Hotstuff em 33%. No entanto, os protocolos de consenso baseados em líderes não conseguem aproveitar totalmente o potencial de throughput do Narwhal. Embora a separação da propagação de dados do consenso tenha sido feita, à medida que o throughput aumenta, o líder do Hotstuff/Jolteon ainda está limitado.
Assim, decidiu-se implementar 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 traz um custo de latência de 50%.
Este artigo apresenta como a Shoal pode reduzir significativamente a latência do Bullshark.
Contexto do DAG-BFT
Em um DAG Narwhal, cada vértice está associado a uma 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 ponto no tempo.
Uma propriedade chave do DAG é a não ambiguidade: se dois nós de validação têm o mesmo vértice v na visão local do DAG, então eles têm a mesma história causal de v.
Ordem 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 no Narwhal existentes têm a seguinte estrutura:
Ponto de ancoragem reservado: a cada algumas rodadas (, como em duas rodadas ) no Bullshark, há um líder previamente determinado, cujo pico é chamado de ponto de ancoragem.
Pontos de ancoragem de ordenação: os validadores decidem de forma independente, mas determinística, quais pontos de ancoragem encomendar e quais pular.
Ordenação da história causal: os validadores processam um por um a lista de âncoras ordenadas, para cada âncora, ordenando todos os vértices anteriores não ordenados em sua história causal por meio de regras determinísticas.
A chave para garantir a segurança é assegurar que, no passo (2), todos os nós de verificação honestos criem uma lista de ancoragem ordenada, de modo que todas as listas compartilhem o mesmo prefixo. No Shoal, as seguintes observações são feitas sobre todos os protocolos acima mencionados:
Todos os validadores concordam com o primeiro ponto âncora ordenado.
Bullshark latência
A latência do Bullshark depende do número de voltas entre os pontos âncora ordenados no DAG. Embora a parte mais prática do Bullshark na versão sincronizada tenha uma latência melhor do que a versão assíncrona, ainda está longe de ser a ideal.
Questão 1: Gota média de bloco. No Bullshark, cada rodada par tem um ponto âncora, enquanto os vértices da rodada ímpar são interpretados como votos. Em condições normais, são necessárias duas rodadas do DAG para ordenar os pontos âncora; no entanto, os vértices na história causal dos pontos âncora precisam de mais rodadas para que os pontos âncora sejam ordenados. Em condições normais, os vértices na rodada ímpar precisam de três rodadas, e 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 falha, por outro lado, se um líder de rodada não conseguir transmitir o ponto de ancoragem rapidamente o suficiente, não será possível ordenar o ponto de ancoragem (, portanto, será pulado ), todos os vértices não ordenados das rodadas anteriores devem esperar que o próximo ponto de ancoragem seja ordenado. Isso reduz significativamente o desempenho da rede de replicação geográfica, especialmente porque o Bullshark utiliza o tempo limite para esperar 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 pipeline, permitindo que cada rodada tenha âncoras e reduzindo a latência de todos os vértices não âncoras no DAG para três rodadas. Shoal também introduziu um mecanismo de reputação de líder de custo zero no DAG, o que favorece a escolha por líderes rápidos.
Desafio
No contexto do protocolo DAG, a reputação da linha de montagem e do líder é considerada um problema difícil, pelas seguintes razões:
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 selecionada dinamicamente com base no desempenho passado dos validadores para escolher futuros líderes, a ideia dos âncoras no Bullshark (. Embora existam divergências sobre a identidade do líder que não violam a segurança desses protocolos, isso pode levar a uma ordenação completamente diferente no Bullshark, o que levanta o problema central de que escolher âncoras rotativas de forma dinâmica e determinística é necessário para resolver o consenso, e os validadores precisam chegar a um consenso sobre a história ordenada para escolher futuras âncoras.
Como evidência da dificuldade do problema, a implementação do Bullshark, incluindo a implementação atual no ambiente de produção, não suporta essas características.
Protocolo
Apesar dos desafios mencionados, a solução está oculta por trás da 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 todos os validadores concordando com a percepção central do primeiro ponto de ancoragem ordenado, o Shoal combina sequencialmente várias instâncias Bullshark para processá-las em pipeline, tornando ) o primeiro ponto de ancoragem ordenado o ponto de troca das instâncias, e ( a história causal do ponto de ancoragem usada para calcular a reputação do líder.
V que mapeia a rodada para o líder. O Shoal executa uma instância do Bullshark de cada vez, de forma que para cada instância, o âncora é determinado previamente pelo mapeamento F. Cada instância solicita um âncora, o que desencadeia a transição para a próxima instância.
No início, o Shoal lançou a primeira instância do Bullshark na primeira rodada do DAG e a executou até determinar o primeiro ponto de ancoragem ordenado, como na rodada r. Todos os validadores concordaram com este ponto de ancoragem. Assim, 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 encomende um âncora em cada rodada. O ponto de ancoragem da primeira rodada é ordenado pelo primeiro exemplo. Em seguida, o Shoal inicia um novo exemplo na segunda rodada, que por si só tem um ponto de ancoragem, que é ordenado por esse exemplo, e então, outro novo exemplo encomenda um ponto de ancoragem na terceira rodada, e o processo continua.
Durante a ordenação do Bullshark, ao pular pontos de ancoragem, a latência aumenta. Nesse caso, a técnica de pipeline é ineficaz, pois não é possível iniciar novas instâncias antes que a ancoragem da instância anterior seja ordenada. O Shoal garante que seja improvável escolher o líder correspondente para lidar com os pontos de ancoragem perdidos no futuro, atribuindo pontuações a cada nó de validação com base no histórico de atividade recente de cada nó de validação, utilizando um mecanismo de reputação. Os validadores que respondem e participam do protocolo receberão pontuações altas; caso contrário, os nós de validação receberão pontuações baixas, pois podem estar em colapso, lentos ou agindo de má-fé.
A sua ideia é recalcular de forma determinística o mapeamento pré-definido F, que vai do turno ao líder, sempre que a pontuação é atualizada, favorecendo líderes com pontuações mais altas. Para que os validadores cheguem a um consenso sobre o novo mapeamento, 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 se combinar naturalmente, pois ambas utilizam a mesma tecnologia central, que é reinterpretar o DAG após alcançar 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, o validador apenas precisa calcular um novo mapeamento F' a partir da r+1-ésima rodada, com base na história causal das âncoras ordenadas na r-ésima rodada. Em seguida, os nós de validação começam a usar a função de seleção de âncoras 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 limite também aumentará significativamente a latência, pois é muito importante configurá-los adequadamente, e geralmente é necessário ajustá-los dinamicamente, pois depende fortemente do ambiente ) rede (. Antes de se transferir para o próximo líder, o protocolo pagará a penalidade total de latência de tempo limite para líderes com falha. Portanto, as configurações de tempo limite não podem ser excessivamente conservadoras, mas se o tempo limite for muito curto, o protocolo pode ignorar bons líderes. Por exemplo, observamos que, em condições de alta carga, os líderes no Jolteon/Hotstuff ficam sobrecarregados e o tempo limite já expirou antes que eles conseguissem avançar.
Infelizmente, protocolos baseados em líderes como Hotstuff e Jolteon) essencialmente requerem Gota para garantir que o protocolo possa progredir sempre que um líder falhar. Sem Gota, até mesmo líderes que falharam podem parar o protocolo para sempre. Como não é possível distinguir entre falhas durante períodos assíncronos.
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.
23 Curtidas
Recompensa
23
6
Compartilhar
Comentário
0/400
VirtualRichDream
· 07-25 11:15
latência caiu tanto, aptos vão Até à lua
Ver originalResponder0
CoffeeNFTs
· 07-22 19:02
Esta Gota de latência é um pouco atraente.
Ver originalResponder0
RugDocDetective
· 07-22 19:01
Muito bom! Esperei muito tempo, finalmente saiu a solução Aptos!
Ver originalResponder0
RuntimeError
· 07-22 19:00
será que esta nova moda da aptos realmente funciona?
Ver originalResponder0
UnluckyValidator
· 07-22 18:58
A latência alta finalmente chegou ao fim. Estive em apuros por meio ano.
O framework Shoal reduz significativamente a latência do Bullshark na cadeia Aptos, melhorando entre 40-80%.
Estrutura Shoal: Como Gota a latência do Bullshark na Aptos?
Visão geral
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 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 com falhas.
Shoal é uma estrutura que melhora qualquer protocolo de consenso baseado em Narwhal ( como DAG-Rider, Tusk, Bullshark ) através de pipeline e reputação do líder. O pipeline reduz a latência na ordenação do DAG ao introduzir um ponto de âncora em cada rodada, enquanto a reputação do líder melhora ainda mais o problema da latência assegurando que o ponto de âncora esteja associado aos nós de validação mais rápidos. Além disso, a reputação do líder permite que Shoal aproveite a construção de DAG assíncrona para eliminar os tempos limite em todos os cenários. Isso permite que Shoal ofereça propriedades de resposta universal, incluindo a resposta otimista normalmente necessária.
Esta tecnologia é muito simples, envolvendo a execução sequencial de várias instâncias do protocolo subjacente. Assim, quando instanciamos com Bullshark, obtemos um grupo de "tubarões" que estão participando de uma corrida de revezamento.
Motivação
Na busca por alto desempenho em redes de blockchain, tem-se prestado atenção à Gota da 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 atingiu apenas 3500 TPS, muito abaixo da meta de 100k+ TPS.
Recent breakthroughs stem from the realization that data propagation is the main bottleneck based on leader protocols, which can benefit from parallelization. The Narwhal system separates data propagation from core consensus logic, proposing an architecture where all validators propagate data simultaneously, while the consensus component only orders a small amount of metadata. The Narwhal paper reported a throughput of 160,000 TPS.
Anteriormente, apresentamos o Quorum Store, que separa a propagação de dados do consenso, e como usá-lo para escalar o atual protocolo de consenso Jolteon. Jolteon é um protocolo baseado em líderes, que combina o caminho rápido linear do Tendermint e a mudança de vista no estilo PBFT, capaz de reduzir a latência do Hotstuff em 33%. No entanto, os protocolos de consenso baseados em líderes não conseguem aproveitar totalmente o potencial de throughput do Narwhal. Embora a separação da propagação de dados do consenso tenha sido feita, à medida que o throughput aumenta, o líder do Hotstuff/Jolteon ainda está limitado.
Assim, decidiu-se implementar 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 traz um custo de latência de 50%.
Este artigo apresenta como a Shoal pode reduzir significativamente a latência do Bullshark.
Contexto do DAG-BFT
Em um DAG Narwhal, cada vértice está associado a uma 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 ponto no tempo.
Uma propriedade chave do DAG é a não ambiguidade: se dois nós de validação têm o mesmo vértice v na visão local do DAG, então eles têm a mesma história causal de v.
Ordem 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 no Narwhal existentes têm a seguinte estrutura:
Ponto de ancoragem reservado: a cada algumas rodadas (, como em duas rodadas ) no Bullshark, há um líder previamente determinado, cujo pico é chamado de ponto de ancoragem.
Pontos de ancoragem de ordenação: os validadores decidem de forma independente, mas determinística, quais pontos de ancoragem encomendar e quais pular.
Ordenação da história causal: os validadores processam um por um a lista de âncoras ordenadas, para cada âncora, ordenando todos os vértices anteriores não ordenados em sua história causal por meio de regras determinísticas.
A chave para garantir a segurança é assegurar que, no passo (2), todos os nós de verificação honestos criem uma lista de ancoragem ordenada, de modo que todas as listas compartilhem o mesmo prefixo. No Shoal, as seguintes observações são feitas sobre todos os protocolos acima mencionados:
Todos os validadores concordam com o primeiro ponto âncora ordenado.
Bullshark latência
A latência do Bullshark depende do número de voltas entre os pontos âncora ordenados no DAG. Embora a parte mais prática do Bullshark na versão sincronizada tenha uma latência melhor do que a versão assíncrona, ainda está longe de ser a ideal.
Questão 1: Gota média de bloco. No Bullshark, cada rodada par tem um ponto âncora, enquanto os vértices da rodada ímpar são interpretados como votos. Em condições normais, são necessárias duas rodadas do DAG para ordenar os pontos âncora; no entanto, os vértices na história causal dos pontos âncora precisam de mais rodadas para que os pontos âncora sejam ordenados. Em condições normais, os vértices na rodada ímpar precisam de três rodadas, e 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 falha, por outro lado, se um líder de rodada não conseguir transmitir o ponto de ancoragem rapidamente o suficiente, não será possível ordenar o ponto de ancoragem (, portanto, será pulado ), todos os vértices não ordenados das rodadas anteriores devem esperar que o próximo ponto de ancoragem seja ordenado. Isso reduz significativamente o desempenho da rede de replicação geográfica, especialmente porque o Bullshark utiliza o tempo limite para esperar 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 pipeline, permitindo que cada rodada tenha âncoras e reduzindo a latência de todos os vértices não âncoras no DAG para três rodadas. Shoal também introduziu um mecanismo de reputação de líder de custo zero no DAG, o que favorece a escolha por líderes rápidos.
Desafio
No contexto do protocolo DAG, a reputação da linha de montagem e do líder é considerada um problema difícil, pelas seguintes razões:
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 selecionada dinamicamente com base no desempenho passado dos validadores para escolher futuros líderes, a ideia dos âncoras no Bullshark (. Embora existam divergências sobre a identidade do líder que não violam a segurança desses protocolos, isso pode levar a uma ordenação completamente diferente no Bullshark, o que levanta o problema central de que escolher âncoras rotativas de forma dinâmica e determinística é necessário para resolver o consenso, e os validadores precisam chegar a um consenso sobre a história ordenada para escolher futuras âncoras.
Como evidência da dificuldade do problema, a implementação do Bullshark, incluindo a implementação atual no ambiente de produção, não suporta essas características.
Protocolo
Apesar dos desafios mencionados, a solução está oculta por trás da 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 todos os validadores concordando com a percepção central do primeiro ponto de ancoragem ordenado, o Shoal combina sequencialmente várias instâncias Bullshark para processá-las em pipeline, tornando ) o primeiro ponto de ancoragem ordenado o ponto de troca das instâncias, e ( a história causal do ponto de ancoragem usada para calcular a reputação do líder.
![万字详解Shoal框架：如何减少Aptos上的Bullshark latência？])https://img-cdn.gateio.im/webp-social/moments-0b0928cb6240e994c1514c75e080a4b2.webp(
Linha de Produção
V que mapeia a rodada para o líder. O Shoal executa uma instância do Bullshark de cada vez, de forma que para cada instância, o âncora é determinado previamente pelo mapeamento F. Cada instância solicita um âncora, o que desencadeia a transição para a próxima instância.
No início, o Shoal lançou a primeira instância do Bullshark na primeira rodada do DAG e a executou até determinar o primeiro ponto de ancoragem ordenado, como na rodada r. Todos os validadores concordaram com este ponto de ancoragem. Assim, 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 encomende um âncora em cada rodada. O ponto de ancoragem da primeira rodada é ordenado pelo primeiro exemplo. Em seguida, o Shoal inicia um novo exemplo na segunda rodada, que por si só tem um ponto de ancoragem, que é ordenado por esse exemplo, e então, outro novo exemplo encomenda um ponto de ancoragem 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 a ordenação do Bullshark, ao pular pontos de ancoragem, a latência aumenta. Nesse caso, a técnica de pipeline é ineficaz, pois não é possível iniciar novas instâncias antes que a ancoragem da instância anterior seja ordenada. O Shoal garante que seja improvável escolher o líder correspondente para lidar com os pontos de ancoragem perdidos no futuro, atribuindo pontuações a cada nó de validação com base no histórico de atividade recente de cada nó de validação, utilizando um mecanismo de reputação. Os validadores que respondem e participam do protocolo receberão pontuações altas; caso contrário, os nós de validação receberão pontuações baixas, pois podem estar em colapso, lentos ou agindo de má-fé.
A sua ideia é recalcular de forma determinística o mapeamento pré-definido F, que vai do turno ao líder, sempre que a pontuação é atualizada, favorecendo líderes com pontuações mais altas. Para que os validadores cheguem a um consenso sobre o novo mapeamento, 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 se combinar naturalmente, pois ambas utilizam a mesma tecnologia central, que é reinterpretar o DAG após alcançar 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, o validador apenas precisa calcular um novo mapeamento F' a partir da r+1-ésima rodada, com base na história causal das âncoras ordenadas na r-ésima rodada. Em seguida, os nós de validação começam a usar a função de seleção de âncoras atualizada F' para executar uma nova instância do Bullshark a partir da r+1-ésima rodada.
![万字详解Shoal框架：如何减少Aptos上的Bullshark Gota？])https://img-cdn.gateio.im/webp-social/moments-9f789cb669f6fcc244ea7ff7648e48b4.webp(
Não há 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 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 limite também aumentará significativamente a latência, pois é muito importante configurá-los adequadamente, e geralmente é necessário ajustá-los dinamicamente, pois depende fortemente do ambiente ) rede (. Antes de se transferir para o próximo líder, o protocolo pagará a penalidade total de latência de tempo limite para líderes com falha. Portanto, as configurações de tempo limite não podem ser excessivamente conservadoras, mas se o tempo limite for muito curto, o protocolo pode ignorar bons líderes. Por exemplo, observamos que, em condições de alta carga, os líderes no Jolteon/Hotstuff ficam sobrecarregados e o tempo limite já expirou antes que eles conseguissem avançar.
Infelizmente, protocolos baseados em líderes como Hotstuff e Jolteon) essencialmente requerem Gota para garantir que o protocolo possa progredir sempre que um líder falhar. Sem Gota, até mesmo líderes que falharam podem parar o protocolo para sempre. Como não é possível distinguir entre falhas durante períodos assíncronos.