Estrutura Shoal: uma solução inovadora para reduzir a latência do Bullshark na Aptos
Aptos Labs recentemente fez um grande avanço na área de DAG BFT, resolvendo dois problemas-chave, reduzindo significativamente a latência e eliminando pela primeira vez a necessidade de tempo limite em protocolos determinísticos. No geral, em situações sem falhas, a latência do Bullshark melhorou em 40%, e em situações com falhas, melhorou em 80%.
Shoal é um framework que melhora qualquer protocolo de consenso baseado em Narwhal (, como DAG-Rider, Tusk, Bullshark ), através de processamento em pipeline e reputação de líderes. O processamento em 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 ao garantir 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 os tempos limite em todos os cenários. Isso permite que Shoal ofereça o que chamamos de "responsividade universal", que inclui a responsividade otimista geralmente necessária.
A nossa tecnologia é muito simples, consiste essencialmente em múltiplas instâncias de protocolos subjacentes a serem executadas em sequência. Assim, quando instanciamos o Bullshark, obtemos um grupo de "tubarões" a correr numa corrida de estafetas.
Contexto e Motivação
Na busca por um alto desempenho de redes blockchain, a redução da complexidade de comunicação sempre foi o foco, mas essa abordagem não trouxe um aumento significativo na taxa de transferência. Por exemplo, a versão inicial do Diem implementou o Hotstuff, que alcançou apenas 3500 TPS, muito abaixo da meta de mais de 100.000 TPS.
As recentes quebras originaram-se da percepção de que a propagação de dados é o principal gargalo baseado no protocolo dos líderes, podendo beneficiar-se 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, e o componente de consenso apenas ordena uma pequena quantidade de metadados. O artigo do Narwhal reportou uma taxa de transferência de 160.000 TPS.
Anteriormente, apresentamos o Quorum Store, nossa implementação do Narwhal que separa a propagação de dados do consenso, e como usá-lo para escalar o atual protocolo de consenso Jolteon. Jolteon é um protocolo baseado em líder, que combina o caminho rápido linear do Tendermint e a mudança de visão no estilo PBFT, podendo reduzir a latência do Hotstuff em 33%. No entanto, é evidente que os protocolos de consenso baseados em líder não conseguem aproveitar plenamente o potencial de throughput do Narwhal. Embora a separação da propagação de dados do consenso tenha sido realizada, à medida que o throughput aumenta, o líder do Hotstuff/Jolteon ainda é limitado.
Portanto, decidimos implantar o Bullshark sobre o Narwhal DAG, um protocolo de consenso com custo de comunicação zero. Infelizmente, a estrutura DAG que suporta o alto throughput do Bullshark traz um custo de latência de 50% em comparação com o Jolteon.
Este artigo apresenta como o Shoal reduz significativamente a latência do Bullshark.
Contexto 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 da rodada r-1. Cada validador pode transmitir um vértice a cada rodada, e cada vértice deve referenciar pelo menos n-f vértices da rodada anterior. Devido à assíncronia da rede, diferentes validadores podem observar diferentes visões locais do DAG em qualquer ponto no tempo.
Uma propriedade chave do DAG é a não ambiguidade: se dois nós de validação têm o mesmo vértice v em sua visão local do DAG, então eles têm exatamente a mesma história causal de v.
Ordem 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 em Narwhal existentes possuem a seguinte estrutura:
Ponto de ancoragem: A cada algumas rodadas (, como nas duas rodadas ) do Bullshark, haverá um líder previamente determinado, cujo pico é chamado de ponto de ancoragem.
Pontos de Ancoragem de Ordenação: os validadores decidem de forma independente, mas determinística, quais pontos de ancoragem ordenar e quais pontos de ancoragem ignorar.
Ordenar a história causal: os validadores processam uma lista de âncoras ordenadas, um após o outro, classificando todos os vértices anteriores não ordenados em sua história causal para cada âncora, de acordo com algumas regras determinísticas.
A chave para garantir a segurança é assegurar que, no passo (2), todas as listas de âncoras ordenadas criadas pelos nós de validação honestos 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 âncora ordenado.
Bullshark latência
A latência do Bullshark depende do número de voltas entre os âncoras 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: latência média do bloco. No Bullshark, cada rodada par tem um ponto de ancoragem, enquanto os vértices da rodada ímpar são interpretados como votos. Em condições comuns, são necessárias duas rodadas de DAG para classificar os pontos de ancoragem; no entanto, os vértices na história causal dos pontos de ancoragem requerem mais rodadas para esperar que os pontos de ancoragem sejam classificados. Em condiçõ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: Casos de falha de latência. A análise de latência acima aplica-se a situações sem falhas; por outro lado, se o líder de uma rodada não conseguir transmitir os pontos de ancoragem rapidamente o suficiente, não será possível ordenar os pontos de ancoragem (, portanto, serão pulados ). Assim, todos os vértices não ordenados nas rodadas anteriores devem aguardar que o próximo ponto de ancoragem seja ordenado. Isso pode reduzir significativamente o desempenho da rede de replicação geográfica, especialmente porque o Bullshark usa timeouts para esperar pelo líder.
Estrutura Shoal
Shoal melhorou o Bullshark( ou qualquer outro protocolo BFT baseado em Narwhal) através do processamento em pipeline, permitindo que haja um ponto de âncora a 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 custo zero no DAG, o que faz com que a escolha se incline para líderes rápidos.
Desafio
No contexto do protocolo DAG, o processamento em 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 sua natureza, impossíveis.
A reputação do líder é introduzida no DiemBFT e formalizada no Carousel, sendo escolhida dinamicamente com base no desempenho passado dos validadores para futuros líderes, a ideia dos pontos âncora no 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 a questão central de que a escolha dinâmica e determinística dos âncoras rotativas é necessária para resolver o consenso, e os validadores precisam chegar a um consenso sobre a história ordenada para escolher âncoras futuras.
Como evidência da dificuldade do problema, notamos que a implementação do Bullshark, incluindo a implementação atualmente em ambiente de produção, não suporta essas características.
Acordo
Apesar dos desafios mencionados acima, a solução está escondida na simplicidade.
No Shoal, dependemos da capacidade de executar cálculos locais sobre o DAG e conseguimos preservar e reinterpretar as 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 do Bullshark para processá-las em pipeline, fazendo com que ) o primeiro ponto âncora ordenado seja o ponto de troca das instâncias, assim como ( a história causal do ponto âncora é usada para calcular a reputação dos líderes.
![Explicação detalhada do framework Shoal: como reduzir a latência do Bullshark na Aptos?])https://img-cdn.gateio.im/webp-social/moments-46d37add0d9e81b2f295edf8eddd907f.webp(
) processamento em linha
V que mapeia as rodadas para os líderes. Shoal executa instâncias do Bullshark uma após a outra, de modo que, para cada instância, o âncora é determinado previamente pelo mapeamento F. Cada instância classifica um âncora, o que desencadeia a transição para a próxima instância.
No início, 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 concordam com este ponto de ancoragem. Assim, todos os validadores podem concordar de forma confiável em reinterpretar o DAG a partir da rodada r+1. O Shoal apenas iniciou uma nova instância do Bullshark na rodada r+1.
No melhor dos casos, isso permite que o Shoal classifique um âncora em cada rodada. O ponto de âncora da primeira rodada é classificado 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 então, outra nova instância classifica o ponto de âncora na terceira rodada, e o processo continua.
reputação do líder
Durante o período de ordenação do Bullshark, a latência aumenta ao pular pontos âncora. Nesse caso, a técnica de processamento em pipeline é impotente, pois não é possível iniciar uma nova instância antes do ponto âncora da instância anterior estar ordenado. O Shoal assegura que é menos provável que líderes correspondentes sejam escolhidos para lidar com pontos âncora perdidos no futuro, atribuindo uma pontuação a cada nó de validação com base no histórico de atividades recentes de cada nó de validação, através do uso de um mecanismo de reputação. 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 falhar, ser lentos ou agir de forma maliciosa.
A sua ideia é recalcular de forma determinística o mapeamento predefinido F do ciclo até o líder sempre que a pontuação for atualizada, favorecendo os líderes com pontuações mais altas. Para que os validadores cheguem a um consenso sobre o novo mapeamento, 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, o processamento em pipeline e a reputação do líder podem se combinar naturalmente, uma vez que ambos utilizam a mesma tecnologia central, ou seja, reinterpretar o DAG após alcançar consenso sobre o primeiro ponto âncora ordenado.
Na verdade, a única diferença é que, após a ordenação dos âncoras na r-ésima rodada, os validadores precisam apenas calcular um novo mapeamento F' a partir da rodada r+1, com base na história causal das âncoras ordenadas na r-ésima rodada. Em seguida, os nós de validação começam a usar a função de seleção de âncoras atualizada F' para executar uma nova instância do Bullshark a partir da rodada r+1.
não há mais tempo limite
O tempo limite desempenha um papel crucial em todas as implementações BFT de sincronização determinística 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 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 ( na rede ). Antes de passar para o próximo líder, o protocolo pagará a penalidade de latência total do líder com falha. Portanto, as configurações de tempo limite não podem ser excessivamente conservadoras, mas se o tempo limite for muito curto, o protocolo pode pular bons líderes. 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 que eles conseguissem avançar.
Infelizmente, o protocolo baseado no líder ###, como Hotstuff e Jolteon (, necessita essencialmente de latência para garantir que cada vez que o líder falha.
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.
13 gostos
Recompensa
13
6
Republicar
Partilhar
Comentar
0/400
SandwichDetector
· 7h atrás
O aumento de desempenho é realmente bull, um aumento de 80% é impressionante.
Ver originalResponder0
NFTRegretful
· 7h atrás
Parece estar bem, só que a velocidade ainda não é rápida o suficiente.
Ver originalResponder0
BearMarketSurvivor
· 7h atrás
Gota de 80% isso é uma força sólida no campo de batalha, ansioso pelo desempenho em combate
Ver originalResponder0
CoinBasedThinking
· 7h atrás
Projeto confiável de atualização técnica. Espero que não seja um começo promissor seguido de um fim decepcionante.
Shoal framework melhora a eficiência do consenso Aptos Gota Bullshark latência reduzida em 80%
Estrutura Shoal: uma solução inovadora para reduzir a latência do Bullshark na Aptos
Aptos Labs recentemente fez um grande avanço na área de DAG BFT, resolvendo dois problemas-chave, reduzindo significativamente a latência e eliminando pela primeira vez a necessidade de tempo limite em protocolos determinísticos. No geral, em situações sem falhas, a latência do Bullshark melhorou em 40%, e em situações com falhas, melhorou em 80%.
Shoal é um framework que melhora qualquer protocolo de consenso baseado em Narwhal (, como DAG-Rider, Tusk, Bullshark ), através de processamento em pipeline e reputação de líderes. O processamento em 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 ao garantir 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 os tempos limite em todos os cenários. Isso permite que Shoal ofereça o que chamamos de "responsividade universal", que inclui a responsividade otimista geralmente necessária.
A nossa tecnologia é muito simples, consiste essencialmente em múltiplas instâncias de protocolos subjacentes a serem executadas em sequência. Assim, quando instanciamos o Bullshark, obtemos um grupo de "tubarões" a correr numa corrida de estafetas.
Contexto e Motivação
Na busca por um alto desempenho de redes blockchain, a redução da complexidade de comunicação sempre foi o foco, mas essa abordagem não trouxe um aumento significativo na taxa de transferência. Por exemplo, a versão inicial do Diem implementou o Hotstuff, que alcançou apenas 3500 TPS, muito abaixo da meta de mais de 100.000 TPS.
As recentes quebras originaram-se da percepção de que a propagação de dados é o principal gargalo baseado no protocolo dos líderes, podendo beneficiar-se 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, e o componente de consenso apenas ordena uma pequena quantidade de metadados. O artigo do Narwhal reportou uma taxa de transferência de 160.000 TPS.
Anteriormente, apresentamos o Quorum Store, nossa implementação do Narwhal que separa a propagação de dados do consenso, e como usá-lo para escalar o atual protocolo de consenso Jolteon. Jolteon é um protocolo baseado em líder, que combina o caminho rápido linear do Tendermint e a mudança de visão no estilo PBFT, podendo reduzir a latência do Hotstuff em 33%. No entanto, é evidente que os protocolos de consenso baseados em líder não conseguem aproveitar plenamente o potencial de throughput do Narwhal. Embora a separação da propagação de dados do consenso tenha sido realizada, à medida que o throughput aumenta, o líder do Hotstuff/Jolteon ainda é limitado.
Portanto, decidimos implantar o Bullshark sobre o Narwhal DAG, um protocolo de consenso com custo de comunicação zero. Infelizmente, a estrutura DAG que suporta o alto throughput do Bullshark traz um custo de latência de 50% em comparação com o Jolteon.
Este artigo apresenta como o Shoal reduz significativamente a latência do Bullshark.
Contexto 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 da rodada r-1. Cada validador pode transmitir um vértice a cada rodada, e cada vértice deve referenciar pelo menos n-f vértices da rodada anterior. Devido à assíncronia da rede, diferentes validadores podem observar diferentes visões locais do DAG em qualquer ponto no tempo.
Uma propriedade chave do DAG é a não ambiguidade: se dois nós de validação têm o mesmo vértice v em sua visão local do DAG, então eles têm exatamente a mesma história causal de v.
Ordem 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 em Narwhal existentes possuem a seguinte estrutura:
Ponto de ancoragem: A cada algumas rodadas (, como nas duas rodadas ) do Bullshark, haverá um líder previamente determinado, cujo pico é chamado de ponto de ancoragem.
Pontos de Ancoragem de Ordenação: os validadores decidem de forma independente, mas determinística, quais pontos de ancoragem ordenar e quais pontos de ancoragem ignorar.
Ordenar a história causal: os validadores processam uma lista de âncoras ordenadas, um após o outro, classificando todos os vértices anteriores não ordenados em sua história causal para cada âncora, de acordo com algumas regras determinísticas.
A chave para garantir a segurança é assegurar que, no passo (2), todas as listas de âncoras ordenadas criadas pelos nós de validação honestos 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 âncora ordenado.
Bullshark latência
A latência do Bullshark depende do número de voltas entre os âncoras 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: latência média do bloco. No Bullshark, cada rodada par tem um ponto de ancoragem, enquanto os vértices da rodada ímpar são interpretados como votos. Em condições comuns, são necessárias duas rodadas de DAG para classificar os pontos de ancoragem; no entanto, os vértices na história causal dos pontos de ancoragem requerem mais rodadas para esperar que os pontos de ancoragem sejam classificados. Em condiçõ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: Casos de falha de latência. A análise de latência acima aplica-se a situações sem falhas; por outro lado, se o líder de uma rodada não conseguir transmitir os pontos de ancoragem rapidamente o suficiente, não será possível ordenar os pontos de ancoragem (, portanto, serão pulados ). Assim, todos os vértices não ordenados nas rodadas anteriores devem aguardar que o próximo ponto de ancoragem seja ordenado. Isso pode reduzir significativamente o desempenho da rede de replicação geográfica, especialmente porque o Bullshark usa timeouts para esperar pelo líder.
Estrutura Shoal
Shoal melhorou o Bullshark( ou qualquer outro protocolo BFT baseado em Narwhal) através do processamento em pipeline, permitindo que haja um ponto de âncora a 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 custo zero no DAG, o que faz com que a escolha se incline para líderes rápidos.
Desafio
No contexto do protocolo DAG, o processamento em 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 sua natureza, impossíveis.
A reputação do líder é introduzida no DiemBFT e formalizada no Carousel, sendo escolhida dinamicamente com base no desempenho passado dos validadores para futuros líderes, a ideia dos pontos âncora no 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 a questão central de que a escolha dinâmica e determinística dos âncoras rotativas é necessária para resolver o consenso, e os validadores precisam chegar a um consenso sobre a história ordenada para escolher âncoras futuras.
Como evidência da dificuldade do problema, notamos que a implementação do Bullshark, incluindo a implementação atualmente em ambiente de produção, não suporta essas características.
Acordo
Apesar dos desafios mencionados acima, a solução está escondida na simplicidade.
No Shoal, dependemos da capacidade de executar cálculos locais sobre o DAG e conseguimos preservar e reinterpretar as 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 do Bullshark para processá-las em pipeline, fazendo com que ) o primeiro ponto âncora ordenado seja o ponto de troca das instâncias, assim como ( a história causal do ponto âncora é usada para calcular a reputação dos líderes.
![Explicação detalhada do framework Shoal: como reduzir a latência do Bullshark na Aptos?])https://img-cdn.gateio.im/webp-social/moments-46d37add0d9e81b2f295edf8eddd907f.webp(
) processamento em linha
V que mapeia as rodadas para os líderes. Shoal executa instâncias do Bullshark uma após a outra, de modo que, para cada instância, o âncora é determinado previamente pelo mapeamento F. Cada instância classifica um âncora, o que desencadeia a transição para a próxima instância.
No início, 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 concordam com este ponto de ancoragem. Assim, todos os validadores podem concordar de forma confiável em reinterpretar o DAG a partir da rodada r+1. O Shoal apenas iniciou uma nova instância do Bullshark na rodada r+1.
No melhor dos casos, isso permite que o Shoal classifique um âncora em cada rodada. O ponto de âncora da primeira rodada é classificado 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 então, outra nova instância classifica o ponto de âncora na terceira rodada, e o processo continua.
reputação do líder
Durante o período de ordenação do Bullshark, a latência aumenta ao pular pontos âncora. Nesse caso, a técnica de processamento em pipeline é impotente, pois não é possível iniciar uma nova instância antes do ponto âncora da instância anterior estar ordenado. O Shoal assegura que é menos provável que líderes correspondentes sejam escolhidos para lidar com pontos âncora perdidos no futuro, atribuindo uma pontuação a cada nó de validação com base no histórico de atividades recentes de cada nó de validação, através do uso de um mecanismo de reputação. 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 falhar, ser lentos ou agir de forma maliciosa.
A sua ideia é recalcular de forma determinística o mapeamento predefinido F do ciclo até o líder sempre que a pontuação for atualizada, favorecendo os líderes com pontuações mais altas. Para que os validadores cheguem a um consenso sobre o novo mapeamento, 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, o processamento em pipeline e a reputação do líder podem se combinar naturalmente, uma vez que ambos utilizam a mesma tecnologia central, ou seja, reinterpretar o DAG após alcançar consenso sobre o primeiro ponto âncora ordenado.
Na verdade, a única diferença é que, após a ordenação dos âncoras na r-ésima rodada, os validadores precisam apenas calcular um novo mapeamento F' a partir da rodada r+1, com base na história causal das âncoras ordenadas na r-ésima rodada. Em seguida, os nós de validação começam a usar a função de seleção de âncoras atualizada F' para executar uma nova instância do Bullshark a partir da rodada r+1.
não há mais tempo limite
O tempo limite desempenha um papel crucial em todas as implementações BFT de sincronização determinística 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 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 ( na rede ). Antes de passar para o próximo líder, o protocolo pagará a penalidade de latência total do líder com falha. Portanto, as configurações de tempo limite não podem ser excessivamente conservadoras, mas se o tempo limite for muito curto, o protocolo pode pular bons líderes. 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 que eles conseguissem avançar.
Infelizmente, o protocolo baseado no líder ###, como Hotstuff e Jolteon (, necessita essencialmente de latência para garantir que cada vez que o líder falha.