Estrutura Shoal: como reduzir a latência do Bullshark na Aptos?
Resumo
Aptos labs resolveu dois importantes problemas abertos no DAG BFT, Gota significativamente a latência e eliminou pela primeira vez a necessidade de timeouts em protocolos práticos determinísticos. No geral, melhorou a latência do Bullshark em 40% em condições sem falhas e em 80% em condições de falha.
Shoal é um protocolo de consenso baseado em Narwhal que melhora a latência através de uma linha de montagem e da reputação do líder, como os frameworks DAG-Rider, Tusk, Bullshark (. A linha de montagem reduz a latência de ordenação DAG ao introduzir um ponto âncora a cada rodada, enquanto a reputação do líder melhora ainda mais o problema de latência ao garantir que os pontos âncoras estejam associados aos nós de validação mais rápidos. Além disso, a reputação do líder permite que o Shoal utilize construções DAG assíncronas para eliminar timeouts em todos os cenários. Isso permite que o Shoal ofereça uma propriedade chamada resposta universal, que contém a resposta otimista normalmente necessária.
Esta tecnologia é muito simples, envolvendo a execução sequencial de múltiplas instâncias do protocolo subjacente. Assim, quando instanciamos com Bullshark, obtemos um grupo de "tubarões" a realizar uma corrida de estafeta.
![Explicação detalhada do framework Shoal: como reduzir a latência do Bullshark na Aptos?])https://img-cdn.gateio.im/webp-social/moments-8d6acd885bad7b8f911bdce15a7c884f.webp(
Motivação
Na busca por um alto desempenho da rede blockchain, as pessoas sempre se concentraram em Gota a complexidade da 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 de paradigma resultam do reconhecimento de que a propagação de dados é o principal gargalo baseado em protocolos de líderes, e que pode beneficiar-se da paralelização. O sistema Narwhal separa a propagação de dados da lógica de consenso central, propondo uma arquitetura na qual todos os validadores propagam dados simultaneamente, enquanto o componente de consenso apenas ordena uma quantidade reduzida de metadados. O artigo sobre o Narwhal reportou uma taxa de transferência de 160.000 TPS.
No artigo anterior, apresentamos o Quorum Store. A nossa implementação do Narwhal 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íderes que combina o caminho rápido linear do Tendermint e mudanças de vista no estilo PBFT, podendo reduzir a latência do Hotstuff em 33%. No entanto, é claro que os protocolos de consenso baseados em líderes 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 está limitado.
Portanto, decidimos implementar 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 taxa de transferência trouxe um custo de latência de 50%.
Este artigo apresenta como a Shoal consegue reduzir significativamente a latência do Bullshark.
Background do DAG-BFT
Cada vértice no Narwhal DAG está associado a um número de 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íncronidade da rede, diferentes validadores podem observar diferentes visões locais do DAG a qualquer momento.
Uma característica 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 exatamente a mesma história causal de v.
![Explicação detalhada do framework Shoal: como reduzir a latência do Bullshark na Aptos?])https://img-cdn.gateio.im/webp-social/moments-f6b6281c928e3fa7a2412a480c9c1806.webp(
Classificação Geral
É 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 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 baseados no Narwhal existentes possuem a seguinte estrutura:
Ponto de ancoragem: a cada várias rodadas ), por exemplo, em Bullshark, haverá um líder pré-determinado a cada duas rodadas (, cujo pico é chamado de ponto de ancoragem;
Ponto de ancoragem de ordenação: os validadores decidem de forma independente, mas determinística, quais pontos de ancoragem encomendar e quais ignorar;
ordem da história causal: os validadores processam um a um suas listas de âncoras ordenadas e, para cada âncora, ordenam todos os vértices anteriores não ordenados em 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 âncoras ordenadas, de modo 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 âncora ordenado.
A latência do Bullshark depende do número de voltas entre os pontos de â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.
Pergunta 1: média de latência de bloco. No Bullshark, cada rodada par tem um ponto de âncora, e cada ponto de uma rodada ímpar é interpretado como um voto. Em situações comuns, são necessárias duas rodadas de DAG para ordenar os pontos de âncora, no entanto, os pontos na história causal do âncora precisam de mais rodadas para esperar que o âncora seja ordenado. Em situações comuns, os pontos na rodada ímpar precisam de três rodadas, enquanto os pontos que não são âncoras na rodada par precisam de quatro rodadas.
Questão 2: latência em 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 o ponto de âncora rapidamente o suficiente, não será possível classificar o ponto de âncora ) e, portanto, será pulado (. Assim, todos os vértices não classificados das rodadas anteriores devem aguardar que o próximo ponto de âncora seja classificado. Isso irá reduzir significativamente o desempenho da rede de replicação geográfica, especialmente porque o Bullshark utiliza timeout para aguardar o líder.
Shoal resolveu esses dois problemas de latência, aprimorando o Bullshark) ou qualquer outro protocolo BFT baseado em Narwhal( através de um pipeline, permitindo que haja um ponto de ancoragem em cada rodada e reduzindo a latência de todos os vértices não ancorados no DAG para três rodadas. Shoal também introduziu um mecanismo de reputação de líder de zero custo no DAG, o que faz com que a escolha favoreça líderes rápidos.
Desafio
No contexto do protocolo DAG, a reputação da linha de produção 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 de â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 a questão central de que a escolha dinâmica e determinística da âncora rotativa é necessária para resolver o consenso, e os validadores precisam chegar a um acordo sobre a história ordenada para escolher as âncoras futuras.
Como evidência da dificuldade do problema, notamos que a implementação do Bullshark, incluindo a implementação atual em ambiente de produção, não suporta essas características.
Protocolo
Apesar dos desafios mencionados, como diz o ditado, a solução está provada estar escondida na simplicidade.
No Shoal, dependemos da capacidade de executar cálculos locais em DAG e implementamos a capacidade de salvar e reinterpretar informações das rodadas anteriores. Com a visão central de que todos os validadores concordam com o primeiro ponto âncora ordenado, o Shoal combina sequencialmente várias instâncias de Bullshark para processá-las em pipeline, tornando ( o primeiro ponto âncora ordenado o ponto de mudança das instâncias, e ) a história causal do ponto âncora usada para calcular a reputação do líder.
Linha de montagem
V que mapeia a rodada para o líder. O Shoal executa instâncias do Bullshark uma a uma, de modo que para cada instância, o âncora é previamente determinado pelo mapeamento F. Cada instância encomenda um âncora, o que desencadeia 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 de ancoragem ordenado, como na rodada r. Todos os validadores concordaram com esse ponto de ancoragem. Assim, todos os validadores podem concordar de forma conclusiva 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 é classificado pela primeira instância. Em seguida, o Shoal começa uma nova instância na segunda rodada, que possui um ponto de ancoragem, que é classificado por essa instância, e então, outra nova instância encomenda o ponto de ancoragem na terceira rodada, e o processo continua.
Reputação do líder
Durante a classificação Bullshark, ao pular pontos de ancoragem, a latência aumenta. Nesse caso, a tecnologia de pipeline não pode ajudar, pois não é possível iniciar novas instâncias antes de ordernar o ponto de ancoragem da instância anterior. 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, usando 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 falência, lentos ou agindo de forma maliciosa.
A sua filosofia é recalcular de forma determinística o mapeamento predefinido F de cada rodada ao líder sempre que o escore é atualizado, 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 usada para derivar as pontuações.
No Shoal, a linha de montagem e a reputação de liderança podem se combinar naturalmente, uma vez que ambas utilizam a mesma tecnologia central, ou seja, reinterpretar o DAG após alcançar um consenso sobre o primeiro ponto de ancoragem ordenado.
Na verdade, a única diferença é que, após classificar os âncoras na r-ésima rodada, o validador só precisa calcular um novo mapeamento F' a partir da r+1ª rodada, com base na história causal dos âncoras ordenados da 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ª rodada.
Não há mais tempo de espera
O tempo limite desempenha um papel crucial em todas as implementações BFT de sincronização determinística baseadas em líder. 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 limite também aumentará significativamente a latência, pois é muito importante configurá-los adequadamente, e geralmente precisam ser ajustados dinamicamente, pois depende fortemente do ambiente ( rede ). Antes de passar para o próximo líder, o protocolo pagará a penalização completa pelo tempo limite para o líder com falha. Portanto, as configurações de tempo limite não podem ser excessivamente conservadoras, mas se
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.
16 Curtidas
Recompensa
16
6
Repostar
Compartilhar
Comentário
0/400
SlowLearnerWang
· 08-16 21:57
latência reduzida em 40%... esse bug foi corrigido de forma tão bull?
Ver originalResponder0
NFTArchaeologis
· 08-16 21:56
Tal como os caracteres de ossos oraculares gravados na cadeia digital, a inovação da estrutura do Shoal transforma a impureza.
Ver originalResponder0
PumpDetector
· 08-16 21:55
hmm bullshark a ficar mais rápido mas ainda a ler nas entrelinhas... algo parece estar errado ngl
Otimização do framework Shoal para o Consenso Aptos reduz significativamente a latência do Bullshark
Estrutura Shoal: como reduzir a latência do Bullshark na Aptos?
Resumo
Aptos labs resolveu dois importantes problemas abertos no DAG BFT, Gota significativamente a latência e eliminou pela primeira vez a necessidade de timeouts em protocolos práticos determinísticos. No geral, melhorou a latência do Bullshark em 40% em condições sem falhas e em 80% em condições de falha.
Shoal é um protocolo de consenso baseado em Narwhal que melhora a latência através de uma linha de montagem e da reputação do líder, como os frameworks DAG-Rider, Tusk, Bullshark (. A linha de montagem reduz a latência de ordenação DAG ao introduzir um ponto âncora a cada rodada, enquanto a reputação do líder melhora ainda mais o problema de latência ao garantir que os pontos âncoras estejam associados aos nós de validação mais rápidos. Além disso, a reputação do líder permite que o Shoal utilize construções DAG assíncronas para eliminar timeouts em todos os cenários. Isso permite que o Shoal ofereça uma propriedade chamada resposta universal, que contém a resposta otimista normalmente necessária.
Esta tecnologia é muito simples, envolvendo a execução sequencial de múltiplas instâncias do protocolo subjacente. Assim, quando instanciamos com Bullshark, obtemos um grupo de "tubarões" a realizar uma corrida de estafeta.
![Explicação detalhada do framework Shoal: como reduzir a latência do Bullshark na Aptos?])https://img-cdn.gateio.im/webp-social/moments-8d6acd885bad7b8f911bdce15a7c884f.webp(
Motivação
Na busca por um alto desempenho da rede blockchain, as pessoas sempre se concentraram em Gota a complexidade da 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 de paradigma resultam do reconhecimento de que a propagação de dados é o principal gargalo baseado em protocolos de líderes, e que pode beneficiar-se da paralelização. O sistema Narwhal separa a propagação de dados da lógica de consenso central, propondo uma arquitetura na qual todos os validadores propagam dados simultaneamente, enquanto o componente de consenso apenas ordena uma quantidade reduzida de metadados. O artigo sobre o Narwhal reportou uma taxa de transferência de 160.000 TPS.
No artigo anterior, apresentamos o Quorum Store. A nossa implementação do Narwhal 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íderes que combina o caminho rápido linear do Tendermint e mudanças de vista no estilo PBFT, podendo reduzir a latência do Hotstuff em 33%. No entanto, é claro que os protocolos de consenso baseados em líderes 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 está limitado.
Portanto, decidimos implementar 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 taxa de transferência trouxe um custo de latência de 50%.
Este artigo apresenta como a Shoal consegue reduzir significativamente a latência do Bullshark.
Background do DAG-BFT
Cada vértice no Narwhal DAG está associado a um número de 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íncronidade da rede, diferentes validadores podem observar diferentes visões locais do DAG a qualquer momento.
Uma característica 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 exatamente a mesma história causal de v.
![Explicação detalhada do framework Shoal: como reduzir a latência do Bullshark na Aptos?])https://img-cdn.gateio.im/webp-social/moments-f6b6281c928e3fa7a2412a480c9c1806.webp(
Classificação Geral
É 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 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 baseados no Narwhal existentes possuem a seguinte estrutura:
Ponto de ancoragem: a cada várias rodadas ), por exemplo, em Bullshark, haverá um líder pré-determinado a cada duas rodadas (, cujo pico é chamado de ponto de ancoragem;
Ponto de ancoragem de ordenação: os validadores decidem de forma independente, mas determinística, quais pontos de ancoragem encomendar e quais ignorar;
ordem da história causal: os validadores processam um a um suas listas de âncoras ordenadas e, para cada âncora, ordenam todos os vértices anteriores não ordenados em 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 âncoras ordenadas, de modo 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 âncora ordenado.
![万字详解Shoal框架：如何减少Aptos上的Bullshark Gota？])https://img-cdn.gateio.im/webp-social/moments-b7ed8888da112bae8d34c0fdb338b138.webp(
Bullshark latência
A latência do Bullshark depende do número de voltas entre os pontos de â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.
Pergunta 1: média de latência de bloco. No Bullshark, cada rodada par tem um ponto de âncora, e cada ponto de uma rodada ímpar é interpretado como um voto. Em situações comuns, são necessárias duas rodadas de DAG para ordenar os pontos de âncora, no entanto, os pontos na história causal do âncora precisam de mais rodadas para esperar que o âncora seja ordenado. Em situações comuns, os pontos na rodada ímpar precisam de três rodadas, enquanto os pontos que não são âncoras na rodada par precisam de quatro rodadas.
Questão 2: latência em 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 o ponto de âncora rapidamente o suficiente, não será possível classificar o ponto de âncora ) e, portanto, será pulado (. Assim, todos os vértices não classificados das rodadas anteriores devem aguardar que o próximo ponto de âncora seja classificado. Isso irá reduzir significativamente o desempenho da rede de replicação geográfica, especialmente porque o Bullshark utiliza timeout para aguardar o líder.
![万字详解Shoal框架：如何减少Aptos上的Bullshark Gota？])https://img-cdn.gateio.im/webp-social/moments-46d37add0d9e81b2f295edf8eddd907f.webp(
Estrutura Shoal
Shoal resolveu esses dois problemas de latência, aprimorando o Bullshark) ou qualquer outro protocolo BFT baseado em Narwhal( através de um pipeline, permitindo que haja um ponto de ancoragem em cada rodada e reduzindo a latência de todos os vértices não ancorados no DAG para três rodadas. Shoal também introduziu um mecanismo de reputação de líder de zero custo no DAG, o que faz com que a escolha favoreça líderes rápidos.
Desafio
No contexto do protocolo DAG, a reputação da linha de produção 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 de â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 a questão central de que a escolha dinâmica e determinística da âncora rotativa é necessária para resolver o consenso, e os validadores precisam chegar a um acordo sobre a história ordenada para escolher as âncoras futuras.
Como evidência da dificuldade do problema, notamos que a implementação do Bullshark, incluindo a implementação atual em ambiente de produção, não suporta essas características.
Protocolo
Apesar dos desafios mencionados, como diz o ditado, a solução está provada estar escondida na simplicidade.
No Shoal, dependemos da capacidade de executar cálculos locais em DAG e implementamos a capacidade de salvar e reinterpretar informações das rodadas anteriores. Com a visão central de que todos os validadores concordam com o primeiro ponto âncora ordenado, o Shoal combina sequencialmente várias instâncias de Bullshark para processá-las em pipeline, tornando ( o primeiro ponto âncora ordenado o ponto de mudança das instâncias, e ) a história causal do ponto âncora usada para calcular a reputação do líder.
Linha de montagem
V que mapeia a rodada para o líder. O Shoal executa instâncias do Bullshark uma a uma, de modo que para cada instância, o âncora é previamente determinado pelo mapeamento F. Cada instância encomenda um âncora, o que desencadeia 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 de ancoragem ordenado, como na rodada r. Todos os validadores concordaram com esse ponto de ancoragem. Assim, todos os validadores podem concordar de forma conclusiva 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 é classificado pela primeira instância. Em seguida, o Shoal começa uma nova instância na segunda rodada, que possui um ponto de ancoragem, que é classificado por essa instância, e então, outra nova instância encomenda o ponto de ancoragem na terceira rodada, e o processo continua.
Reputação do líder
Durante a classificação Bullshark, ao pular pontos de ancoragem, a latência aumenta. Nesse caso, a tecnologia de pipeline não pode ajudar, pois não é possível iniciar novas instâncias antes de ordernar o ponto de ancoragem da instância anterior. 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, usando 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 falência, lentos ou agindo de forma maliciosa.
A sua filosofia é recalcular de forma determinística o mapeamento predefinido F de cada rodada ao líder sempre que o escore é atualizado, 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 usada para derivar as pontuações.
No Shoal, a linha de montagem e a reputação de liderança podem se combinar naturalmente, uma vez que ambas utilizam a mesma tecnologia central, ou seja, reinterpretar o DAG após alcançar um consenso sobre o primeiro ponto de ancoragem ordenado.
Na verdade, a única diferença é que, após classificar os âncoras na r-ésima rodada, o validador só precisa calcular um novo mapeamento F' a partir da r+1ª rodada, com base na história causal dos âncoras ordenados da 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ª rodada.
Não há mais tempo de espera
O tempo limite desempenha um papel crucial em todas as implementações BFT de sincronização determinística baseadas em líder. 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 limite também aumentará significativamente a latência, pois é muito importante configurá-los adequadamente, e geralmente precisam ser ajustados dinamicamente, pois depende fortemente do ambiente ( rede ). Antes de passar para o próximo líder, o protocolo pagará a penalização completa pelo tempo limite para o líder com falha. Portanto, as configurações de tempo limite não podem ser excessivamente conservadoras, mas se