Estrutura Shoal: como Gota a latência do Bullshark na Aptos
Aptos Labs resolveu recentemente dois importantes problemas abertos no DAG BFT, Gota a latência de forma significativa e eliminou pela primeira vez a necessidade de tempo limite em protocolos de consistência determinística. De forma geral, melhorou a latência do Bullshark em 40% em condições sem falhas e em 80% em condições de falha.
Shoal é uma estrutura que, através de pipelines e da reputação do líder, melhora qualquer protocolo de consenso baseado em Narwhal ( como DAG-Rider, Tusk, Bullshark ). O pipeline reduz a latência de ordenação do DAG ao introduzir um ponto de âncora a cada rodada, enquanto a reputação do líder melhora ainda mais o problema de latência, garantindo que o ponto de âncora esteja associado ao nó de validação mais rápido. Além disso, a reputação do líder permite que Shoal utilize a construção assíncrona do DAG para eliminar timeouts em todos os cenários. Isso permite que Shoal ofereça uma propriedade chamada resposta universal, que inclui a resposta otimista geralmente necessária.
A tecnologia é muito simples, envolvendo a execução, um após o outro, de múltiplas instâncias do protocolo subjacente. Assim, quando instanciada com Bullshark, resulta em um grupo de "tubarões" que estão participando de uma corrida de revezamento.
Contexto
Na busca por alto desempenho em redes blockchain, as pessoas têm se concentrado na Gota da complexidade de comunicação. No entanto, essa abordagem 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, bem abaixo da meta de 100k+ TPS.
As recentes quebras surgem do reconhecimento de que a propagação de dados é o principal gargalo baseado nos protocolos dos líderes, e que pode beneficiar da paralelização. O sistema Narwhal separa a propagação de dados da lógica de consenso central, propondo uma arquitetura onde todos os validadores propagam dados simultaneamente, enquanto o componente de consenso apenas ordena uma pequena quantidade de metadados. O artigo do Narwhal reporta uma capacidade de 160.000 TPS.
No artigo anterior, foi apresentada a Quorum Store, ou seja, a implementação do Narwhal que separa a propagação de dados do consenso, assim como como usá-la 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 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 totalmente 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 é limitado.
Portanto, foi decidido implementar o Bullshark sobre o Narwhal DAG, que é um protocolo de consenso com zero custo de comunicação. Infelizmente, em comparação com o Jolteon, a estrutura DAG que suporta um alto throughput para o Bullshark traz um custo de latência de 50%.
Este artigo apresenta como o Shoal conseguiu reduzir significativamente a latência do Bullshark.
Fundo do DAG-BFT
Cada vértice no DAG do 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 ponto no tempo.
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 suas visões locais 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 custo adicional 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 têm a seguinte estrutura:
Ponto de ancoragem: a cada algumas rodadas haverá um líder pré-determinado, o pico 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 encomendar e quais ignorar;
Ordenação da história causal: os validadores processam um por um a sua lista de âncoras ordenadas e, para cada âncora, ordenam todos os vértices anteriores que estavam desordenados na sua história causal através de algumas regras determinísticas.
A chave para garantir a segurança é assegurar que, no passo (2), todos os nós de validação honestos criem uma lista de pontos de ancoragem ordenada, para que todas as listas compartilhem o mesmo prefixo. No Shoal, fazem-se as seguintes observações sobre todos os protocolos:
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 pontos âncora ordenados no DAG. Embora a versão sincronizada 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: Gota média do bloco. No Bullshark, cada rodada par tem um ponto âncora, e cada rodada ímpar tem seus vértices interpretados como votos. Em situações comuns, são necessárias duas rodadas de DAG para encomendar os pontos âncora; no entanto, os vértices na história causal do âncora precisam de mais rodadas para que o âncora seja ordenado. 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 o ponto de ancoragem rapidamente o suficiente, não será possível classificar o ponto de ancoragem ( e, portanto, será ignorado ), assim todos os vértices não classificados nas primeiras rodadas devem aguardar o próximo ponto de ancoragem ser classificado. Isso irá Gota significativamente o desempenho da rede de replicação geográfica, especialmente porque o Bullshark usa tempo limite para aguardar o 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 pipeline, permitindo que houvesse um ponto de ancoragem em cada rodada e reduzindo a latência de todos os vértices não ancorados no DAG para três rodadas. Shoal também introduziu um mecanismo de reputação de líder sem custo no DAG, o que faz com que a escolha favoreça líderes rápidos.
Desafio
No contexto do protocolo DAG, a reputação da linha de produção e do líder é considerada uma questão difícil, pelos seguintes motivos:
As linhas de montagem anteriores tentaram modificar a lógica central do Bullshark, mas isso parece ser essencialmente impossível.
A reputação dos líderes é introduzida no DiemBFT e formalizada no Carousel, sendo escolhida dinamicamente com base no desempenho passado dos validadores para selecionar futuros líderes, a ideia do âncora no Bullshark (. Embora as divergências sobre a identidade do líder não violem a segurança desses protocolos, no Bullshark, isso pode levar a ordenações completamente diferentes, levantando o cerne da questão, ou seja, a seleção dinâmica e determinística do âncora da rodada é necessária para resolver o consenso, enquanto os validadores precisam chegar a um acordo sobre a história ordenada para selecionar os futuros âncoras.
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.
Protocolo
Apesar dos desafios acima mencionados, a verdade é que a solução está escondida na simplicidade.
No Shoal, aproveitando a capacidade de executar cálculos locais sobre o DAG, e implementando a capacidade de armazenar e reinterpretar informações das rodadas anteriores. Com a percepção central de que todos os validadores concordam com o primeiro ponto de âncora ordenado, o Shoal combina sequencialmente várias instâncias Bullshark e as processa em pipeline, tornando ) o primeiro ponto de âncora ordenado como o ponto de troca das instâncias, e ( a história causal do ponto de âncora utilizada para calcular a reputação dos líderes.
![Explicação detalhada do framework Shoal: como reduzir a latência do Bullshark no Aptos?])https://img-cdn.gateio.im/webp-social/moments-46d37add0d9e81b2f295edf8eddd907f.webp(
Linha de Montagem
V que mapeia rodadas a líderes. Shoal executa instâncias do Bullshark uma a uma, de modo que para cada instância, a âncora é pré-determinada pelo mapeamento F. Cada instância encomenda uma âncora, o que desencadeia a mudança 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é que o primeiro ponto de ancoragem ordenado fosse determinado, como na rodada r. Todos os validadores concordaram com este ponto de ancoragem. Assim, todos os validadores puderam concordar de forma definitiva em reinterpretar o DAG a partir da rodada r+1. O Shoal simplesmente lançou uma nova instância do Bullshark na rodada r+1.
No melhor cenário, isso permite que o Shoal encomende uma âncora em cada rodada. Os pontos de âncora da primeira rodada são ordenados de acordo com a primeira instância. Em seguida, o Shoal inicia uma nova instância na segunda rodada, que por sua vez tem um ponto de âncora, e essa âncora é ordenada por essa instância, depois, outra nova instância encomenda pontos de âncora na terceira rodada, e o processo continua.
Durante a ordenação do Bullshark, ao pular pontos de ancoragem, a latência aumentará. Nessa situação, a técnica de pipeline não é eficaz, pois uma nova instância não pode ser iniciada antes que a instância anterior tenha encomendado o ponto de ancoragem. O Shoal garante que é menos provável que líderes correspondentes sejam escolhidos para lidar com pontos de ancoragem perdidos, atribuindo uma pontuação 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 altas pontuações; caso contrário, os nós de validação receberão baixas pontuações, pois podem estar em colapso, lentos ou agindo de forma maliciosa.
A sua filosofia é recalcular de forma determinística o mapeamento pré-definido 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 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 pipeline e a reputação de liderança podem se combinar naturalmente, pois ambas utilizam a mesma tecnologia central, que é 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. Em seguida, os nós de validação começam a executar uma nova instância do Bullshark a partir da r+1-ésima rodada usando a função de seleção de pontos de ancoragem atualizada F'.
O tempo limite desempenha um papel crucial em todas as implementações BFT determinísticas baseadas em líder. No entanto, a complexidade que elas introduzem aumenta o número de estados internos que precisam ser geridos e observados, o que aumenta a complexidade do processo de depuração e requer mais técnicas de observabilidade.
O tempo limite 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 ) da rede (. Antes de passar para o próximo líder, o protocolo pagará a penalização completa de latência do tempo limite para o líder com falha. Portanto, a configuração do tempo limite não pode ser excessivamente conservadora, mas se o tempo limite for muito curto, o protocolo pode ignorar líderes bons. Por exemplo, observamos que, em situações de alta carga, os líderes no Jolteon/Hotstuff ficam sobrecarregados, e o tempo limite já havia expirado antes de eles avançarem.
Infelizmente, o protocolo do líder ), como o Hotstuff e o Jolteon (, necessita essencialmente de latência para garantir que cada vez o líder
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.
A estrutura Shoal reduz significativamente a latência do Bullshark na Aptos, melhorando entre 40%-80%.
Estrutura Shoal: como Gota a latência do Bullshark na Aptos
Aptos Labs resolveu recentemente dois importantes problemas abertos no DAG BFT, Gota a latência de forma significativa e eliminou pela primeira vez a necessidade de tempo limite em protocolos de consistência determinística. De forma geral, melhorou a latência do Bullshark em 40% em condições sem falhas e em 80% em condições de falha.
Shoal é uma estrutura que, através de pipelines e da reputação do líder, melhora qualquer protocolo de consenso baseado em Narwhal ( como DAG-Rider, Tusk, Bullshark ). O pipeline reduz a latência de ordenação do DAG ao introduzir um ponto de âncora a cada rodada, enquanto a reputação do líder melhora ainda mais o problema de latência, garantindo que o ponto de âncora esteja associado ao nó de validação mais rápido. Além disso, a reputação do líder permite que Shoal utilize a construção assíncrona do DAG para eliminar timeouts em todos os cenários. Isso permite que Shoal ofereça uma propriedade chamada resposta universal, que inclui a resposta otimista geralmente necessária.
A tecnologia é muito simples, envolvendo a execução, um após o outro, de múltiplas instâncias do protocolo subjacente. Assim, quando instanciada com Bullshark, resulta em um grupo de "tubarões" que estão participando de uma corrida de revezamento.
Contexto
Na busca por alto desempenho em redes blockchain, as pessoas têm se concentrado na Gota da complexidade de comunicação. No entanto, essa abordagem 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, bem abaixo da meta de 100k+ TPS.
As recentes quebras surgem do reconhecimento de que a propagação de dados é o principal gargalo baseado nos protocolos dos líderes, e que pode beneficiar da paralelização. O sistema Narwhal separa a propagação de dados da lógica de consenso central, propondo uma arquitetura onde todos os validadores propagam dados simultaneamente, enquanto o componente de consenso apenas ordena uma pequena quantidade de metadados. O artigo do Narwhal reporta uma capacidade de 160.000 TPS.
No artigo anterior, foi apresentada a Quorum Store, ou seja, a implementação do Narwhal que separa a propagação de dados do consenso, assim como como usá-la 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 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 totalmente 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 é limitado.
Portanto, foi decidido implementar o Bullshark sobre o Narwhal DAG, que é um protocolo de consenso com zero custo de comunicação. Infelizmente, em comparação com o Jolteon, a estrutura DAG que suporta um alto throughput para o Bullshark traz um custo de latência de 50%.
Este artigo apresenta como o Shoal conseguiu reduzir significativamente a latência do Bullshark.
Fundo do DAG-BFT
Cada vértice no DAG do 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 ponto no tempo.
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 suas visões locais 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 custo adicional 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 têm a seguinte estrutura:
Ponto de ancoragem: a cada algumas rodadas haverá um líder pré-determinado, o pico 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 encomendar e quais ignorar;
Ordenação da história causal: os validadores processam um por um a sua lista de âncoras ordenadas e, para cada âncora, ordenam todos os vértices anteriores que estavam desordenados na sua história causal através de algumas regras determinísticas.
A chave para garantir a segurança é assegurar que, no passo (2), todos os nós de validação honestos criem uma lista de pontos de ancoragem ordenada, para que todas as listas compartilhem o mesmo prefixo. No Shoal, fazem-se as seguintes observações sobre todos os protocolos:
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 pontos âncora ordenados no DAG. Embora a versão sincronizada 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: Gota média do bloco. No Bullshark, cada rodada par tem um ponto âncora, e cada rodada ímpar tem seus vértices interpretados como votos. Em situações comuns, são necessárias duas rodadas de DAG para encomendar os pontos âncora; no entanto, os vértices na história causal do âncora precisam de mais rodadas para que o âncora seja ordenado. 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 o ponto de ancoragem rapidamente o suficiente, não será possível classificar o ponto de ancoragem ( e, portanto, será ignorado ), assim todos os vértices não classificados nas primeiras rodadas devem aguardar o próximo ponto de ancoragem ser classificado. Isso irá Gota significativamente o desempenho da rede de replicação geográfica, especialmente porque o Bullshark usa tempo limite para aguardar o 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 pipeline, permitindo que houvesse um ponto de ancoragem em cada rodada e reduzindo a latência de todos os vértices não ancorados no DAG para três rodadas. Shoal também introduziu um mecanismo de reputação de líder sem custo no DAG, o que faz com que a escolha favoreça líderes rápidos.
Desafio
No contexto do protocolo DAG, a reputação da linha de produção e do líder é considerada uma questão difícil, pelos seguintes motivos:
As linhas de montagem anteriores tentaram modificar a lógica central do Bullshark, mas isso parece ser essencialmente impossível.
A reputação dos líderes é introduzida no DiemBFT e formalizada no Carousel, sendo escolhida dinamicamente com base no desempenho passado dos validadores para selecionar futuros líderes, a ideia do âncora no Bullshark (. Embora as divergências sobre a identidade do líder não violem a segurança desses protocolos, no Bullshark, isso pode levar a ordenações completamente diferentes, levantando o cerne da questão, ou seja, a seleção dinâmica e determinística do âncora da rodada é necessária para resolver o consenso, enquanto os validadores precisam chegar a um acordo sobre a história ordenada para selecionar os futuros âncoras.
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.
Protocolo
Apesar dos desafios acima mencionados, a verdade é que a solução está escondida na simplicidade.
No Shoal, aproveitando a capacidade de executar cálculos locais sobre o DAG, e implementando a capacidade de armazenar e reinterpretar informações das rodadas anteriores. Com a percepção central de que todos os validadores concordam com o primeiro ponto de âncora ordenado, o Shoal combina sequencialmente várias instâncias Bullshark e as processa em pipeline, tornando ) o primeiro ponto de âncora ordenado como o ponto de troca das instâncias, e ( a história causal do ponto de âncora utilizada para calcular a reputação dos líderes.
![Explicação detalhada do framework Shoal: como reduzir a latência do Bullshark no Aptos?])https://img-cdn.gateio.im/webp-social/moments-46d37add0d9e81b2f295edf8eddd907f.webp(
Linha de Montagem
V que mapeia rodadas a líderes. Shoal executa instâncias do Bullshark uma a uma, de modo que para cada instância, a âncora é pré-determinada pelo mapeamento F. Cada instância encomenda uma âncora, o que desencadeia a mudança 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é que o primeiro ponto de ancoragem ordenado fosse determinado, como na rodada r. Todos os validadores concordaram com este ponto de ancoragem. Assim, todos os validadores puderam concordar de forma definitiva em reinterpretar o DAG a partir da rodada r+1. O Shoal simplesmente lançou uma nova instância do Bullshark na rodada r+1.
No melhor cenário, isso permite que o Shoal encomende uma âncora em cada rodada. Os pontos de âncora da primeira rodada são ordenados de acordo com a primeira instância. Em seguida, o Shoal inicia uma nova instância na segunda rodada, que por sua vez tem um ponto de âncora, e essa âncora é ordenada por essa instância, depois, outra nova instância encomenda pontos de âncora na terceira rodada, e o processo continua.
![万字详解Shoal框架：如何减少Aptos上的Bullshark Gota？])https://img-cdn.gateio.im/webp-social/moments-0b0928cb6240e994c1514c75e080a4b2.webp(
Reputação dos Líderes
Durante a ordenação do Bullshark, ao pular pontos de ancoragem, a latência aumentará. Nessa situação, a técnica de pipeline não é eficaz, pois uma nova instância não pode ser iniciada antes que a instância anterior tenha encomendado o ponto de ancoragem. O Shoal garante que é menos provável que líderes correspondentes sejam escolhidos para lidar com pontos de ancoragem perdidos, atribuindo uma pontuação 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 altas pontuações; caso contrário, os nós de validação receberão baixas pontuações, pois podem estar em colapso, lentos ou agindo de forma maliciosa.
A sua filosofia é recalcular de forma determinística o mapeamento pré-definido 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 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 pipeline e a reputação de liderança podem se combinar naturalmente, pois ambas utilizam a mesma tecnologia central, que é 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. Em seguida, os nós de validação começam a executar uma nova instância do Bullshark a partir da r+1-ésima rodada usando a função de seleção de pontos de ancoragem atualizada F'.
![万字详解Shoal框架：如何减少Aptos上的Bullshark latência？])https://img-cdn.gateio.im/webp-social/moments-859e732e16c3eee0e2c93422474debc2.webp(
Não há mais tempo limite
O tempo limite desempenha um papel crucial em todas as implementações BFT determinísticas baseadas em líder. No entanto, a complexidade que elas introduzem aumenta o número de estados internos que precisam ser geridos e observados, o que aumenta a complexidade do processo de depuração e requer mais técnicas de observabilidade.
O tempo limite 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 ) da rede (. Antes de passar para o próximo líder, o protocolo pagará a penalização completa de latência do tempo limite para o líder com falha. Portanto, a configuração do tempo limite não pode ser excessivamente conservadora, mas se o tempo limite for muito curto, o protocolo pode ignorar líderes bons. Por exemplo, observamos que, em situações de alta carga, os líderes no Jolteon/Hotstuff ficam sobrecarregados, e o tempo limite já havia expirado antes de eles avançarem.
Infelizmente, o protocolo do líder ), como o Hotstuff e o Jolteon (, necessita essencialmente de latência para garantir que cada vez o líder