Estrutura Shoal: Gota significativa na latência do Bullshark em Aptos
Aptos Labs resolveu recentemente dois problemas abertos importantes no DAG BFT, reduzindo significativamente a latência e eliminando pela primeira vez a necessidade de timeouts em protocolos práticos determinísticos. No geral, em situações sem falhas, a latência do Bullshark melhorou em 40%, enquanto em situações de falha melhorou em 80%.
Shoal é uma estrutura que melhora qualquer protocolo de consenso baseado em Narwhal (, como DAG-Rider, Tusk, Bullshark ), através de pipelines e reputação do líder. O pipeline reduz a latência de ordenação DAG ao introduzir um ponto de ancoragem em cada rodada, enquanto a reputação do líder melhora ainda mais a latência, garantindo que os pontos de ancoragem estejam associados aos nós de validação mais rápidos. Além disso, a reputação do líder permite que o Shoal aproveite a construção assíncrona de DAG para eliminar timeouts em todos os cenários. Isso permite que o Shoal ofereça o que chamamos de propriedade de resposta universal, que contém a resposta otimista normalmente necessária.
A nossa tecnologia é muito simples, envolvendo a execução sequencial de múltiplas instâncias do protocolo subjacente. Assim, ao instanciar o Bullshark, obtemos um grupo de "tubarões" que estão a participar numa corrida de estafetas.
Motivação
Na busca por um alto desempenho na rede blockchain, as pessoas sempre se concentraram na latência da comunicação. No entanto, esse método não resultou em um aumento significativo na capacidade de processamento. Por exemplo, o Hotstuff implementado nas versões iniciais do Diem alcançou apenas 3500 TPS, muito abaixo da nossa meta de 100k+ TPS.
No entanto, a recente quebra de paradigma vem do reconhecimento de que a propagação de dados é o principal gargalo baseado no protocolo de líderes e que pode beneficiar-se da paralelização. O sistema Narwhal separa a propagação de dados da lógica central de consenso e propõe uma arquitetura em que todos os validadores propagam dados simultaneamente, enquanto o componente de consenso apenas ordena uma quantidade reduzida de metadados. O documento do 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 a utilizamos para expandir o atual protocolo de consenso Jolteon. O Jolteon é um protocolo baseado em líderes, que combina o caminho rápido linear do Tendermint com mudanças de vista no estilo PBFT, podendo reduzir a latência do Hotstuff em 33%. No entanto, é evidente que os protocolos de consenso baseados em líderes não conseguem aproveitar plenamente o potencial de throughput do Narwhal. Apesar de separar a propagação de dados do consenso, à medida que o throughput aumenta, os líderes do Hotstuff/Jolteon ainda estão limitados.
Assim, decidimos implementar o Bullshark sobre o Narwhal DAG, um protocolo de consenso sem custo de comunicação. Infelizmente, em comparação com o Jolteon, a estrutura DAG que suporta o Bullshark com alta taxa de transferência traz um custo de latência de 50%.
Neste artigo, apresentamos como a Shoal consegue reduzir significativamente a latência do Bullshark.
Contexto do DAG-BFT
Vamos começar por entender o contexto relevante deste artigo.
Cada vértice no Narwhal DAG está associado a uma rodada. Para entrar na rodada r, o validador deve primeiro obter n-f vértices pertencentes à rodada r-1. Cada validador pode transmitir um vértice por rodada, e cada vértice deve referenciar pelo menos n-f vértices da rodada anterior. Devido à assíncronia da rede, diferentes validadores podem observar diferentes visões locais do DAG em qualquer momento.
Uma propriedade chave do DAG não é ambígua: 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.
Classificação geral
É 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 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 em Narwhal existentes têm a seguinte estrutura:
Ponto de ancoragem: a cada algumas rodadas (, por exemplo, em duas rodadas de Bullshark ), haverá um líder previamente determinado, e o pico do líder é chamado de ponto de ancoragem;
Pontos de ancoragem ordenados: os validadores decidem de forma independente, mas determinística, quais pontos de ancoragem encomendar e quais pular;
História causal ordenada: os validadores processam um a um a sua lista de âncoras ordenadas e, para cada âncora, ordenam todos os vértices anteriores não ordenados na sua história causal através de algumas regras determinísticas.
A chave para garantir a segurança é assegurar que, nos passos acima (2), todos os nós de validação honestos criem uma lista de ancoragem ordenada, 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 âncora ordenado.
Bullshark latência
A latência do Bullshark depende do número de voltas entre os âncoras ordenadas no DAG. Embora a versão síncrona mais prática do Bullshark tenha uma latência melhor que a versão assíncrona, ela está longe de ser a ideal.
Pergunta 1: latência média de bloco. No Bullshark, cada rodada par tem um ponto âncora, e o vértice da rodada ímpar é interpretado como um voto. Em situações comuns, são necessárias duas rodadas de DAG para ordenar os pontos âncora, no entanto, os vértices na história causal dos pontos âncora precisam de mais rodadas para aguardar a ordenação dos pontos âncora. 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.
Pergunta 2: latência de casos de falha, a análise de latência acima se aplica a situações sem falha. Por outro lado, se o líder de uma rodada não conseguir transmitir o ponto de ancoragem rapidamente o suficiente, não será possível classificar o ponto de ancoragem ( e, portanto, ele é ignorado ), resultando em todos os vértices não classificados nas rodadas anteriores tendo que esperar pelo próximo ponto de ancoragem a ser classificado. Isso irá Gota significativamente o desempenho da rede de replicação geográfica, especialmente porque o tempo limite Bullshark é usado para esperar pelo líder.
Estrutura Shoal
Shoal resolveu esses dois problemas de latência, aprimorando o Bullshark( ou qualquer outro protocolo BFT baseado em Narwhal) através de pipelines, 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 de pipeline e líder é considerada um problema difícil, pelas seguintes razões:
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 selecionada dinamicamente com base no desempenho passado dos validadores para escolher futuros líderes. A ideia do âncora em (Bullshark. Embora a divergência na identidade do líder não viole a segurança desses protocolos, no Bullshark, isso pode levar a uma ordenação completamente diferente, o que levanta o cerne da questão, ou seja, a seleção dinâmica e determinística do âncora da roda é necessária para resolver o consenso, e os validadores precisam concordar sobre a história ordenada para escolher futuros âncoras.
Como evidência da dificuldade do problema, notamos que a implementação do Bullshark, incluindo a implementação atual no ambiente de produção, não suporta essas características.
Protocolo
Apesar dos desafios mencionados, como diz o provérbio, a solução está provada que se esconde por trás do simples.
No Shoal, confiamos na capacidade de executar cálculos locais sobre o 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, fazendo com que ) o primeiro ponto de ancoragem ordenado seja o ponto de mudança das instâncias, e ( a história causal do ponto de ancoragem é utilizada para calcular a reputação do líder.
V que mapeia as rodadas para os líderes. O Shoal executa instâncias do Bullshark uma após a outra, de modo que para cada instância, a âncora é previamente determinada pelo mapeamento F. Cada instância encomenda uma âncora, o que desencadeia a mudança 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 este ponto de ancoragem. Assim, todos os validadores podem concordar de forma certa 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. Os pontos de âncora da primeira rodada são classificados pela primeira instância. Em seguida, o Shoal inicia uma nova instância na segunda rodada, que por si só tem um ponto de âncora, que é classificado por essa instância, e depois, outra nova instância encomenda pontos de âncora na terceira rodada, e o processo continua.
![Explicação detalhada do Shoal Framework: como reduzir a latência do Bullshark na Aptos?])https://img-cdn.gateio.im/webp-social/moments-0b0928cb6240e994c1514c75e080a4b2.webp(
Reputação do Líder
Durante a ordenação Bullshark, a Gota aumenta ao pular pontos âncora. Nessa situação, a tecnologia de pipeline não consegue ajudar, pois uma nova instância não pode ser iniciada antes que a instância anterior tenha solicitado o ponto âncora. O Shoal garante que é menos provável que líderes correspondentes sejam escolhidos para lidar com pontos âncora 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. Validadores que respondem e participam do protocolo receberão pontuações elevadas, caso contrário, 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 de cada atualização de pontuação de turno para líder, favorecendo os líderes com pontuações mais altas. Para que os validadores cheguem a um consenso sobre o novo mapeamento, eles devem chegar a um consenso sobre a pontuação, alcançando assim um consenso sobre a história utilizada para derivar a pontuação.
No Shoal, a linha de produção e a reputação de liderança podem se combinar naturalmente, pois ambas utilizam a mesma tecnologia central, que é a reinterpretação do DAG após alcançar consenso sobre o primeiro ponto âncora ordenado.
Na verdade, a única diferença é que, após ordenar os pontos de ancoragem 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 dos pontos de ancoragem ordenados na r-ésima rodada. Então, os nós validadores começam a usar a função de seleção de pontos de ancoragem atualizada F' para executar uma nova instância do Bullshark a partir da r+1-ésima rodada.
O tempo limite desempenha um papel crucial em todas as implementações BFT determinísticas baseadas em líderes. No entanto, a complexidade que introduzem aumenta o número de estados internos que precisam ser geridos e monitorizados, 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, pois depende fortemente do ambiente ) da rede (. Antes de passar para o próximo líder, o protocolo pagará uma penalização completa de latência pelo líder com falha. Portanto, a configuração de tempo limite não pode ser excessivamente conservadora, mas se o tempo limite for muito curto, o protocolo pode ignorar bons líderes. Por exemplo, observamos
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.
10 Curtidas
Recompensa
10
6
Compartilhar
Comentário
0/400
FortuneTeller42
· 27m atrás
Isso é incrível, um aumento de 80%!
Ver originalResponder0
StableGeniusDegen
· 07-27 13:52
Tecnologia de ponta! O aumento de preço é iminente
Ver originalResponder0
EthSandwichHero
· 07-26 07:15
A latência Gota? bull bull, é assim que até à lua!
Ver originalResponder0
GasOptimizer
· 07-26 07:14
80% latência otimizada é melhor do que qualquer taxa de gás.
A estrutura Shoal melhora significativamente o desempenho da rede Aptos, com a latência do Bullshark reduzida em 80%.
Estrutura Shoal: Gota significativa na latência do Bullshark em Aptos
Aptos Labs resolveu recentemente dois problemas abertos importantes no DAG BFT, reduzindo significativamente a latência e eliminando pela primeira vez a necessidade de timeouts em protocolos práticos determinísticos. No geral, em situações sem falhas, a latência do Bullshark melhorou em 40%, enquanto em situações de falha melhorou em 80%.
Shoal é uma estrutura que melhora qualquer protocolo de consenso baseado em Narwhal (, como DAG-Rider, Tusk, Bullshark ), através de pipelines e reputação do líder. O pipeline reduz a latência de ordenação DAG ao introduzir um ponto de ancoragem em cada rodada, enquanto a reputação do líder melhora ainda mais a latência, garantindo que os pontos de ancoragem estejam associados aos nós de validação mais rápidos. Além disso, a reputação do líder permite que o Shoal aproveite a construção assíncrona de DAG para eliminar timeouts em todos os cenários. Isso permite que o Shoal ofereça o que chamamos de propriedade de resposta universal, que contém a resposta otimista normalmente necessária.
A nossa tecnologia é muito simples, envolvendo a execução sequencial de múltiplas instâncias do protocolo subjacente. Assim, ao instanciar o Bullshark, obtemos um grupo de "tubarões" que estão a participar numa corrida de estafetas.
Motivação
Na busca por um alto desempenho na rede blockchain, as pessoas sempre se concentraram na latência da comunicação. No entanto, esse método não resultou em um aumento significativo na capacidade de processamento. Por exemplo, o Hotstuff implementado nas versões iniciais do Diem alcançou apenas 3500 TPS, muito abaixo da nossa meta de 100k+ TPS.
No entanto, a recente quebra de paradigma vem do reconhecimento de que a propagação de dados é o principal gargalo baseado no protocolo de líderes e que pode beneficiar-se da paralelização. O sistema Narwhal separa a propagação de dados da lógica central de consenso e propõe uma arquitetura em que todos os validadores propagam dados simultaneamente, enquanto o componente de consenso apenas ordena uma quantidade reduzida de metadados. O documento do 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 a utilizamos para expandir o atual protocolo de consenso Jolteon. O Jolteon é um protocolo baseado em líderes, que combina o caminho rápido linear do Tendermint com mudanças de vista no estilo PBFT, podendo reduzir a latência do Hotstuff em 33%. No entanto, é evidente que os protocolos de consenso baseados em líderes não conseguem aproveitar plenamente o potencial de throughput do Narwhal. Apesar de separar a propagação de dados do consenso, à medida que o throughput aumenta, os líderes do Hotstuff/Jolteon ainda estão limitados.
Assim, decidimos implementar o Bullshark sobre o Narwhal DAG, um protocolo de consenso sem custo de comunicação. Infelizmente, em comparação com o Jolteon, a estrutura DAG que suporta o Bullshark com alta taxa de transferência traz um custo de latência de 50%.
Neste artigo, apresentamos como a Shoal consegue reduzir significativamente a latência do Bullshark.
Contexto do DAG-BFT
Vamos começar por entender o contexto relevante deste artigo.
Cada vértice no Narwhal DAG está associado a uma rodada. Para entrar na rodada r, o validador deve primeiro obter n-f vértices pertencentes à rodada r-1. Cada validador pode transmitir um vértice por rodada, e cada vértice deve referenciar pelo menos n-f vértices da rodada anterior. Devido à assíncronia da rede, diferentes validadores podem observar diferentes visões locais do DAG em qualquer momento.
Uma propriedade chave do DAG não é ambígua: 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.
Classificação geral
É 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 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 em Narwhal existentes têm a seguinte estrutura:
Ponto de ancoragem: a cada algumas rodadas (, por exemplo, em duas rodadas de Bullshark ), haverá um líder previamente determinado, e o pico do líder é chamado de ponto de ancoragem;
Pontos de ancoragem ordenados: os validadores decidem de forma independente, mas determinística, quais pontos de ancoragem encomendar e quais pular;
História causal ordenada: os validadores processam um a um a sua lista de âncoras ordenadas e, para cada âncora, ordenam todos os vértices anteriores não ordenados na sua história causal através de algumas regras determinísticas.
A chave para garantir a segurança é assegurar que, nos passos acima (2), todos os nós de validação honestos criem uma lista de ancoragem ordenada, 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 âncora ordenado.
Bullshark latência
A latência do Bullshark depende do número de voltas entre os âncoras ordenadas no DAG. Embora a versão síncrona mais prática do Bullshark tenha uma latência melhor que a versão assíncrona, ela está longe de ser a ideal.
Pergunta 1: latência média de bloco. No Bullshark, cada rodada par tem um ponto âncora, e o vértice da rodada ímpar é interpretado como um voto. Em situações comuns, são necessárias duas rodadas de DAG para ordenar os pontos âncora, no entanto, os vértices na história causal dos pontos âncora precisam de mais rodadas para aguardar a ordenação dos pontos âncora. 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.
Pergunta 2: latência de casos de falha, a análise de latência acima se aplica a situações sem falha. Por outro lado, se o líder de uma rodada não conseguir transmitir o ponto de ancoragem rapidamente o suficiente, não será possível classificar o ponto de ancoragem ( e, portanto, ele é ignorado ), resultando em todos os vértices não classificados nas rodadas anteriores tendo que esperar pelo próximo ponto de ancoragem a ser classificado. Isso irá Gota significativamente o desempenho da rede de replicação geográfica, especialmente porque o tempo limite Bullshark é usado para esperar pelo líder.
Estrutura Shoal
Shoal resolveu esses dois problemas de latência, aprimorando o Bullshark( ou qualquer outro protocolo BFT baseado em Narwhal) através de pipelines, 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 de pipeline e líder é considerada um problema difícil, pelas seguintes razões:
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 selecionada dinamicamente com base no desempenho passado dos validadores para escolher futuros líderes. A ideia do âncora em (Bullshark. Embora a divergência na identidade do líder não viole a segurança desses protocolos, no Bullshark, isso pode levar a uma ordenação completamente diferente, o que levanta o cerne da questão, ou seja, a seleção dinâmica e determinística do âncora da roda é necessária para resolver o consenso, e os validadores precisam concordar sobre a história ordenada para escolher futuros âncoras.
Como evidência da dificuldade do problema, notamos que a implementação do Bullshark, incluindo a implementação atual no ambiente de produção, não suporta essas características.
Protocolo
Apesar dos desafios mencionados, como diz o provérbio, a solução está provada que se esconde por trás do simples.
No Shoal, confiamos na capacidade de executar cálculos locais sobre o 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, fazendo com que ) o primeiro ponto de ancoragem ordenado seja o ponto de mudança das instâncias, e ( a história causal do ponto de ancoragem é utilizada para calcular a reputação do líder.
![万字详解Shoal框架：如何减少Aptos上的Bullshark Gota？])https://img-cdn.gateio.im/webp-social/moments-46d37add0d9e81b2f295edf8eddd907f.webp(
Linha de Montagem
V que mapeia as rodadas para os líderes. O Shoal executa instâncias do Bullshark uma após a outra, de modo que para cada instância, a âncora é previamente determinada pelo mapeamento F. Cada instância encomenda uma âncora, o que desencadeia a mudança 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 este ponto de ancoragem. Assim, todos os validadores podem concordar de forma certa 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. Os pontos de âncora da primeira rodada são classificados pela primeira instância. Em seguida, o Shoal inicia uma nova instância na segunda rodada, que por si só tem um ponto de âncora, que é classificado por essa instância, e depois, outra nova instância encomenda pontos de âncora na terceira rodada, e o processo continua.
![Explicação detalhada do Shoal Framework: como reduzir a latência do Bullshark na Aptos?])https://img-cdn.gateio.im/webp-social/moments-0b0928cb6240e994c1514c75e080a4b2.webp(
Reputação do Líder
Durante a ordenação Bullshark, a Gota aumenta ao pular pontos âncora. Nessa situação, a tecnologia de pipeline não consegue ajudar, pois uma nova instância não pode ser iniciada antes que a instância anterior tenha solicitado o ponto âncora. O Shoal garante que é menos provável que líderes correspondentes sejam escolhidos para lidar com pontos âncora 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. Validadores que respondem e participam do protocolo receberão pontuações elevadas, caso contrário, 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 de cada atualização de pontuação de turno para líder, favorecendo os líderes com pontuações mais altas. Para que os validadores cheguem a um consenso sobre o novo mapeamento, eles devem chegar a um consenso sobre a pontuação, alcançando assim um consenso sobre a história utilizada para derivar a pontuação.
No Shoal, a linha de produção e a reputação de liderança podem se combinar naturalmente, pois ambas utilizam a mesma tecnologia central, que é a reinterpretação do DAG após alcançar consenso sobre o primeiro ponto âncora ordenado.
Na verdade, a única diferença é que, após ordenar os pontos de ancoragem 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 dos pontos de ancoragem ordenados na r-ésima rodada. Então, os nós validadores começam a usar a função de seleção de pontos de ancoragem atualizada F' para executar uma nova instância do Bullshark a partir da r+1-ésima rodada.
![万字详解Shoal框架：如何减少Aptos上的Bullshark Gota？])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íderes. No entanto, a complexidade que introduzem aumenta o número de estados internos que precisam ser geridos e monitorizados, 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, pois depende fortemente do ambiente ) da rede (. Antes de passar para o próximo líder, o protocolo pagará uma penalização completa de latência pelo líder com falha. Portanto, a configuração de tempo limite não pode ser excessivamente conservadora, mas se o tempo limite for muito curto, o protocolo pode ignorar bons líderes. Por exemplo, observamos