Shoal estrutura: Gota significativa na latência do Bullshark em Aptos
Recentemente, os Aptos labs resolveram dois problemas abertos importantes 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, a estrutura Shoal melhorou a latência do Bullshark em 40% em casos sem falhas e em 80% em casos com falhas.
Shoal é um framework que melhora qualquer protocolo de consenso baseado em Narwhal (, como DAG-Rider, Tusk, Bullshark ), através de um mecanismo de pipeline e reputação de líderes. O pipeline reduz a latência de ordenação DAG ao introduzir âncoras em cada rodada, enquanto a reputação de líderes melhora ainda mais a latência garantindo que as âncoras estejam associadas aos nós de validação mais rápidos. Além disso, a reputação de líderes permite que Shoal aproveite a construção assíncrona de DAG para eliminar timeouts em todos os cenários. Isso permite que Shoal ofereça uma característica chamada resposta universal, que contém a resposta otimista normalmente necessária.
A ideia central do Shoal é bastante simples, que é executar múltiplas instâncias do protocolo subjacente em sequência. 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 um alto desempenho da rede blockchain, as pessoas têm se concentrado na Gota 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 na versão inicial do Diem alcançou apenas 3500 TPS, muito abaixo da meta de 100.000+ TPS.
As recentes inovações decorrem da compreensão de que a propagação de dados é o principal gargalo baseado em protocolos de liderança, que pode ser beneficiado pela 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 sobre Narwhal reportou uma capacidade de 160.000 TPS.
Em artigos anteriores, apresentamos o Quorum Store - nossa implementação do Narwhal, que separa a propagação de dados do consenso, e como o utilizamos para expandir o atual protocolo de consenso Jolteon. Jolteon é um protocolo baseado em líder que combina o caminho rápido linear do Tendermint e a mudança de visão ao estilo PBFT, podendo reduzir a latência do Hotstuff em 33%. No entanto, é evidente que 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, os líderes do Hotstuff/Jolteon ainda estão limitados.
Portanto, decidimos implantar o Bullshark sobre o Narwhal DAG, que é um protocolo de consenso com custo de comunicação zero. Infelizmente, em comparação com o Jolteon, a estrutura DAG que suporta o Bullshark com alta capacidade de processamento traz um custo de latência de 50%.
Este artigo apresenta como o Shoal consegue Gota significativamente a latência do Bullshark.
Background 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 à assimetria da rede, diferentes validadores podem observar diferentes visões locais do DAG em qualquer ponto no tempo.
Uma característica chave do DAG é a sua univocidade: se dois nós de validação têm o mesmo vértice v em sua visão local do DAG, então eles têm a mesma história causal de v.
Prefácio
É possível alcançar a consistência 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 têm a seguinte estrutura:
Ponto de ancoragem: a cada algumas rodadas (, como em duas rodadas ) no Bullshark, haverá um líder designado, e o ponto mais alto do líder é chamado de ponto de ancoragem.
Pontos de ancoragem de ordenação: os validadores determinam de forma independente, mas determinística, quais pontos de ancoragem ordenar e quais pular.
Ordenação da história causal: os validadores processam um a um a lista de âncoras ordenadas, e para cada âncora, ordenam todos os vértices anteriores não ordenados em sua história causal, através de 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 âncoras ordenada, para 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 voltas entre os pontos âncora 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 assim está longe de ser a ideal.
Questão 1: latência média de bloco. No Bullshark, cada rodada par tem um ponto âncora, e os vértices da rodada ímpar são interpretados como votos. Em casos comuns, são necessárias duas rodadas de DAG para ordenar os pontos âncoras; no entanto, os vértices na história causal do ponto âncora precisam de mais rodadas para esperar que os pontos âncoras sejam ordenados. Em casos comuns, os vértices na rodada ímpar precisam de três rodadas, enquanto os vértices não âncoras 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 rapidamente o ponto âncora, não será possível classificar o ponto âncora (, que será portanto pulado ). Assim, todos os vértices não classificados nas primeiras rodadas devem aguardar a próxima classificação do ponto âncora. Isso reduzirá 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, melhorando o Bullshark( ou qualquer outro protocolo BFT baseado em Narwhal) através de um pipeline, permitindo que haja um ponto âncora em cada rodada e reduzindo a latência de todos os vértices não âncoras 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 seleção 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, pelos seguintes motivos:
As tentativas anteriores de modificar a lógica central do Bullshark pareciam, por essência, impossíveis.
A reputação dos líderes é introduzida no DiemBFT e formalizada no Carousel, sendo selecionados dinamicamente futuros líderes com base no desempenho passado dos validadores, a ideia dos âncoras no Bullshark. Embora haja divergências na identidade do líder, o que não viola a segurança desses protocolos, no Bullshark, isso pode resultar em ordenações completamente diferentes, o que leva ao cerne da questão, ou seja, a seleção dinâmica e determinística dos âncoras de rodada é necessária para resolver o consenso, e os validadores precisam concordar sobre a história ordenada para selecionar os futuros âncoras.
Como evidência da dificuldade do problema, notamos que 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 verdade é que a solução está escondida na simplicidade.
No Shoal, dependemos da capacidade de executar cálculos locais na DAG e implementamos a capacidade de salvar e reinterpretar informações das rodadas anteriores. Com a percepção central de que todos os validadores concordam com o 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 como o ponto de troca das instâncias, e ) a história causal do ponto de ancoragem utilizada para calcular a reputação do líder.
Linha de produção
V que mapeia as rodadas para os líderes. Shoal executa instâncias do Bullshark uma após a outra, de forma que para cada instância, a âncora é determinada previamente pelo mapeamento F. Cada instância ordena uma â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é que o primeiro ponto âncora ordenado fosse determinado, como na rodada r. Todos os validadores concordaram com esse ponto âncora. Assim, todos os validadores puderam concordar de forma confiável em reinterpretar o DAG a partir da rodada r+1. O Shoal apenas lançou uma nova instância do Bullshark na rodada r+1.
No melhor cenário, isso permite que o Shoal classifique um âncora em cada rodada. O ponto de anclagem da primeira rodada é classificado pelo primeiro instância. Em seguida, o Shoal inicia uma nova instância na segunda rodada, que possui um ponto de anclagem, e esse âncora é classificado por essa instância, e então, outra nova instância classifica o ponto de anclagem na terceira rodada, e esse processo continua.
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 é incapaz, pois não é possível iniciar uma nova instância antes da ordenação do ponto de ancoragem da instância anterior. O Shoal assegura que é menos provável que os líderes correspondentes sejam escolhidos para lidar com os pontos de ancoragem perdidos no futuro, atribuindo uma pontuação a cada nó de validação com base na história da atividade recente de cada nó de validação, através de um mecanismo de reputação. 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 falhar, ser lentos ou agir de forma maliciosa.
A sua filosofia é recalcular de forma determinística o mapeamento pré-definido F, que vai da rodada ao líder, sempre que houver uma atualização de pontuação, favorecendo os líderes com pontuação mais alta. 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, ou seja, reinterpretar o DAG após alcançar consenso no primeiro ponto âncora ordenado.
Na verdade, a única diferença é que, após classificar os pontos âncora na rodada r, o validador só precisa calcular um novo mapeamento F' a partir da rodada r+1, com base na história causal dos pontos âncora ordenados na rodada r. 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 rodada r+1.
Não há mais tempo 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 pode 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 mudar para o próximo líder, o protocolo paga a penalidade completa de latência do tempo de espera para o líder com falha. 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 ignorar bons líderes. Por exemplo, observamos que, sob alta carga, os líderes no Jolteon/Hotstuff estavam sobrecarregados e o tempo de espera já havia expirado antes que eles conseguissem fazer progressos.
Infelizmente, o protocolo baseado em líderes ( como 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.
16 gostos
Recompensa
16
10
Partilhar
Comentar
0/400
TokenomicsTrapper
· 07-16 23:24
clássico vc fumaça e espelhos... 40% não significa nada se a latência base era lixo, para ser honesto
Ver originalResponder0
rekt_but_resilient
· 07-16 17:01
latência cai em 80%? Até à lua
Ver originalResponder0
NestedFox
· 07-16 09:09
A melhoria a oitenta graus está fantástica.
Ver originalResponder0
Blockwatcher9000
· 07-15 13:37
Ainda a vencer a latência, forte
Ver originalResponder0
GasFeePhobia
· 07-14 02:57
40 não é 80, é muito forte? O efeito é bom.
Ver originalResponder0
MEVHunterBearish
· 07-14 02:55
Isso serve para quê? Nós estamos em alta, não estamos a cair.
Ver originalResponder0
WalletsWatcher
· 07-14 02:55
Ah, finalmente resolvemos a latência.
Ver originalResponder0
CryptoFortuneTeller
· 07-14 02:45
Comprar aptos, comprar aptos, está quase a acabar tudo.
O framework Shoal reduziu significativamente a latência do Bullshark na Aptos, alcançando um consenso determinístico sem tempo de espera.
Shoal estrutura: Gota significativa na latência do Bullshark em Aptos
Recentemente, os Aptos labs resolveram dois problemas abertos importantes 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, a estrutura Shoal melhorou a latência do Bullshark em 40% em casos sem falhas e em 80% em casos com falhas.
Shoal é um framework que melhora qualquer protocolo de consenso baseado em Narwhal (, como DAG-Rider, Tusk, Bullshark ), através de um mecanismo de pipeline e reputação de líderes. O pipeline reduz a latência de ordenação DAG ao introduzir âncoras em cada rodada, enquanto a reputação de líderes melhora ainda mais a latência garantindo que as âncoras estejam associadas aos nós de validação mais rápidos. Além disso, a reputação de líderes permite que Shoal aproveite a construção assíncrona de DAG para eliminar timeouts em todos os cenários. Isso permite que Shoal ofereça uma característica chamada resposta universal, que contém a resposta otimista normalmente necessária.
A ideia central do Shoal é bastante simples, que é executar múltiplas instâncias do protocolo subjacente em sequência. 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 um alto desempenho da rede blockchain, as pessoas têm se concentrado na Gota 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 na versão inicial do Diem alcançou apenas 3500 TPS, muito abaixo da meta de 100.000+ TPS.
As recentes inovações decorrem da compreensão de que a propagação de dados é o principal gargalo baseado em protocolos de liderança, que pode ser beneficiado pela 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 sobre Narwhal reportou uma capacidade de 160.000 TPS.
Em artigos anteriores, apresentamos o Quorum Store - nossa implementação do Narwhal, que separa a propagação de dados do consenso, e como o utilizamos para expandir o atual protocolo de consenso Jolteon. Jolteon é um protocolo baseado em líder que combina o caminho rápido linear do Tendermint e a mudança de visão ao estilo PBFT, podendo reduzir a latência do Hotstuff em 33%. No entanto, é evidente que 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, os líderes do Hotstuff/Jolteon ainda estão limitados.
Portanto, decidimos implantar o Bullshark sobre o Narwhal DAG, que é um protocolo de consenso com custo de comunicação zero. Infelizmente, em comparação com o Jolteon, a estrutura DAG que suporta o Bullshark com alta capacidade de processamento traz um custo de latência de 50%.
Este artigo apresenta como o Shoal consegue Gota significativamente a latência do Bullshark.
Background 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 à assimetria da rede, diferentes validadores podem observar diferentes visões locais do DAG em qualquer ponto no tempo.
Uma característica chave do DAG é a sua univocidade: se dois nós de validação têm o mesmo vértice v em sua visão local do DAG, então eles têm a mesma história causal de v.
Prefácio
É possível alcançar a consistência 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 têm a seguinte estrutura:
Ponto de ancoragem: a cada algumas rodadas (, como em duas rodadas ) no Bullshark, haverá um líder designado, e o ponto mais alto do líder é chamado de ponto de ancoragem.
Pontos de ancoragem de ordenação: os validadores determinam de forma independente, mas determinística, quais pontos de ancoragem ordenar e quais pular.
Ordenação da história causal: os validadores processam um a um a lista de âncoras ordenadas, e para cada âncora, ordenam todos os vértices anteriores não ordenados em sua história causal, através de 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 âncoras ordenada, para 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 voltas entre os pontos âncora 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 assim está longe de ser a ideal.
Questão 1: latência média de bloco. No Bullshark, cada rodada par tem um ponto âncora, e os vértices da rodada ímpar são interpretados como votos. Em casos comuns, são necessárias duas rodadas de DAG para ordenar os pontos âncoras; no entanto, os vértices na história causal do ponto âncora precisam de mais rodadas para esperar que os pontos âncoras sejam ordenados. Em casos comuns, os vértices na rodada ímpar precisam de três rodadas, enquanto os vértices não âncoras 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 rapidamente o ponto âncora, não será possível classificar o ponto âncora (, que será portanto pulado ). Assim, todos os vértices não classificados nas primeiras rodadas devem aguardar a próxima classificação do ponto âncora. Isso reduzirá 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, melhorando o Bullshark( ou qualquer outro protocolo BFT baseado em Narwhal) através de um pipeline, permitindo que haja um ponto âncora em cada rodada e reduzindo a latência de todos os vértices não âncoras 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 seleção 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, pelos seguintes motivos:
As tentativas anteriores de modificar a lógica central do Bullshark pareciam, por essência, impossíveis.
A reputação dos líderes é introduzida no DiemBFT e formalizada no Carousel, sendo selecionados dinamicamente futuros líderes com base no desempenho passado dos validadores, a ideia dos âncoras no Bullshark. Embora haja divergências na identidade do líder, o que não viola a segurança desses protocolos, no Bullshark, isso pode resultar em ordenações completamente diferentes, o que leva ao cerne da questão, ou seja, a seleção dinâmica e determinística dos âncoras de rodada é necessária para resolver o consenso, e os validadores precisam concordar sobre a história ordenada para selecionar os futuros âncoras.
Como evidência da dificuldade do problema, notamos que 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 verdade é que a solução está escondida na simplicidade.
No Shoal, dependemos da capacidade de executar cálculos locais na DAG e implementamos a capacidade de salvar e reinterpretar informações das rodadas anteriores. Com a percepção central de que todos os validadores concordam com o 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 como o ponto de troca das instâncias, e ) a história causal do ponto de ancoragem utilizada para calcular a reputação do líder.
Linha de produção
V que mapeia as rodadas para os líderes. Shoal executa instâncias do Bullshark uma após a outra, de forma que para cada instância, a âncora é determinada previamente pelo mapeamento F. Cada instância ordena uma â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é que o primeiro ponto âncora ordenado fosse determinado, como na rodada r. Todos os validadores concordaram com esse ponto âncora. Assim, todos os validadores puderam concordar de forma confiável em reinterpretar o DAG a partir da rodada r+1. O Shoal apenas lançou uma nova instância do Bullshark na rodada r+1.
No melhor cenário, isso permite que o Shoal classifique um âncora em cada rodada. O ponto de anclagem da primeira rodada é classificado pelo primeiro instância. Em seguida, o Shoal inicia uma nova instância na segunda rodada, que possui um ponto de anclagem, e esse âncora é classificado por essa instância, e então, outra nova instância classifica o ponto de anclagem na terceira rodada, e esse processo continua.
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 é incapaz, pois não é possível iniciar uma nova instância antes da ordenação do ponto de ancoragem da instância anterior. O Shoal assegura que é menos provável que os líderes correspondentes sejam escolhidos para lidar com os pontos de ancoragem perdidos no futuro, atribuindo uma pontuação a cada nó de validação com base na história da atividade recente de cada nó de validação, através de um mecanismo de reputação. 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 falhar, ser lentos ou agir de forma maliciosa.
A sua filosofia é recalcular de forma determinística o mapeamento pré-definido F, que vai da rodada ao líder, sempre que houver uma atualização de pontuação, favorecendo os líderes com pontuação mais alta. 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, ou seja, reinterpretar o DAG após alcançar consenso no primeiro ponto âncora ordenado.
Na verdade, a única diferença é que, após classificar os pontos âncora na rodada r, o validador só precisa calcular um novo mapeamento F' a partir da rodada r+1, com base na história causal dos pontos âncora ordenados na rodada r. 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 rodada r+1.
Não há mais tempo 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 pode 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 mudar para o próximo líder, o protocolo paga a penalidade completa de latência do tempo de espera para o líder com falha. 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 ignorar bons líderes. Por exemplo, observamos que, sob alta carga, os líderes no Jolteon/Hotstuff estavam sobrecarregados e o tempo de espera já havia expirado antes que eles conseguissem fazer progressos.
Infelizmente, o protocolo baseado em líderes ( como Hotstuff