Otimização do consenso DAG: Como a estrutura Shoal pode reduzir a latência do Bullshark na Aptos
Aptos Labs recentemente resolveu dois importantes problemas abertos no DAG BFT, reduzindo significativamente a latência e eliminando pela primeira vez a necessidade de timeouts em protocolos assíncronos determinísticos. No geral, a estrutura Shoal melhorou a latência do Bullshark em 40% em condições sem falhas e em 80% em condições de falha.
Shoal é um protocolo que melhora o protocolo de consenso baseado em Narwhal ( através de pipelines e da reputação dos líderes, como os frameworks DAG-Rider, Tusk, Bullshark ). O pipeline reduz a latência de ordenação do DAG ao introduzir um ponto de ancoragem a 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 Shoal utilize a construção de DAG assíncrono para eliminar os tempos limite em todos os cenários. Isso permite que Shoal forneça uma responsividade universal, incluindo a responsividade otimista que normalmente é necessária.
A tecnologia do Shoal é relativamente simples, envolvendo a execução em sequência de várias instâncias do protocolo subjacente. Quando instanciamos com Bullshark, obtemos um grupo de "tubarões" que estão participando de uma corrida de revezamento.
Motivação
Ao buscar um alto desempenho em redes de blockchain, as pessoas têm se concentrado na redução da complexidade de comunicação. No entanto, essa abordagem não resultou em um aumento significativo na taxa de transferência. Por exemplo, o Hotstuff implementado nas versões iniciais do Diem alcançou apenas 3500 TPS, muito abaixo da meta de 100k+ TPS.
Recent breakthroughs stem from the realization that data propagation is the main bottleneck based on leader protocols and can benefit from parallelization. The Narwhal system separates data propagation from core Consenso logic, proposing an architecture where all validators propagate data simultaneously, while the consensus component only orders a small amount of metadata. The Narwhal paper reports a throughput of 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 usá-la para escalar o protocolo de consenso atual Jolteon. O Jolteon é um protocolo baseado em líderes, que combina o caminho rápido linear do Tendermint com as mudanças de vista no estilo PBFT, conseguindo reduzir a latência do Hotstuff em 33%. No entanto, os protocolos de consenso baseados em líderes claramente não conseguem aproveitar totalmente o potencial de throughput do Narwhal. Apesar de a propagação de dados estar separada do consenso, com o aumento do throughput, o líder do Hotstuff/Jolteon ainda está limitado.
Assim, decidimos implementar o Bullshark sobre o DAG Narwhal, 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 traz um custo de latência de 50%.
Este artigo apresenta como a Shoal reduziu significativamente a latência do Bullshark.
Contexto DAG-BFT
Cada vértice no DAG do Narwhal está associado a um número de rodada. Para entrar na rodada r, um validador deve primeiro obter n-f vértices que pertencem à rodada r-1. Cada validador pode transmitir um vértice por rodada, e cada vértice deve referenciar pelo menos n-f vértices da rodada anterior. Devido à assíncronia da rede, diferentes validadores podem observar diferentes visões locais do DAG em qualquer ponto no tempo.
Uma característica chave do DAG é a não ambiguidade: se dois nós de validação tiverem o mesmo vértice v na visão local do DAG, então eles têm a mesma história causal de v.
Ordem Total
É possível alcançar consenso total sobre 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 existentes baseados em Narwhal têm a seguinte estrutura:
Ponto de ancoragem: a cada algumas rodadas há um líder previamente determinado, cujo vértice é 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 pular.
Ordem da história causal: os validadores processam um por um a lista de âncoras ordenadas, classificando todos os vértices não ordenados anteriores na história causal de cada âncora.
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 esses protocolos:
Todos os validadores concordam com o primeiro ponto âncora ordenado.
Bullshark latência
A latência do Bullshark depende do número de rondas 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 está longe de ser a ideal.
Pergunta 1: latência média do bloco. No Bullshark, cada rodada par tem um ponto âncora, e os vértices da rodada ímpar são interpretados como votos. Em situações comuns, são necessárias duas rodadas de DAG para classificar os pontos âncora, no entanto, os vértices na história causal dos pontos âncora precisam de mais rodadas para serem classificados. Normalmente, 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: Situação de falha de latência. Se o líder de uma rodada não conseguir transmitir rapidamente o ponto de ancoragem, não será possível classificar o ponto de ancoragem (, portanto, será ignorado ), todos os vértices não classificados das rodadas anteriores devem aguardar que o próximo ponto de ancoragem seja classificado. Isso pode 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 melhorou o Bullshark( ou qualquer outro protocolo BFT baseado em Narwhal) através de uma linha de montagem, permitindo que haja um ponto de ancoragem a cada rodada e reduzindo a latência de todos os vértices não ancorados no DAG para três rodadas. Shoal também introduziu um mecanismo de reputação de líder sem custo no DAG, fazendo 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, pelas seguintes razões:
As tentativas anteriores de modificar a lógica central do Bullshark parecem ser essencialmente impossíveis.
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 do ancla no Bullshark (. Embora a divergência na identidade do líder não viole a segurança desses protocolos, pode resultar em ordenações completamente diferentes no Bullshark, o que traz à tona o núcleo do problema: escolher anclas de roda de forma dinâmica e determinística é necessário para resolver o consenso, e os validadores precisam concordar sobre a história ordenada para escolher futuros anclas.
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 solução está escondida na simplicidade.
No Shoal, confiamos na capacidade de executar cálculos locais sobre o DAG e implementamos a capacidade de armazenar e reinterpretar informações de rodadas anteriores. Com todas as validações concordando com a principal percepção do primeiro ponto âncora ordenado, Shoal combina sequencialmente várias instâncias de Bullshark para processamento em pipeline, tornando ) o primeiro ponto âncora ordenado como o ponto de troca das instâncias, e ( 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(
Linha de Produção
V que mapeia a rodada para o líder. O Shoal executa instâncias do Bullshark uma após a outra, de modo que para cada instância, o âncora é previamente determinado pelo mapeamento F. Cada instância classifica um âncora, acionando a mudança para a próxima instância.
Inicialmente, o Shoal lançou a primeira instância do Bullshark na primeira rodada do DAG e funcionou até que o primeiro ponto de ancoragem ordenado fosse determinado, como na rodada r. Todos os validadores concordaram com este ponto de ancoragem. Assim, todos os validadores puderam concordar com segurança em reinterpretar o DAG a partir da rodada r+1. O Shoal simplesmente lançou uma nova instância do Bullshark na rodada r+1.
No melhor cenário, isso permite que o Shoal classifique um âncora a 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 sua vez possui um ponto de âncora, esse âncora é classificado por essa instância, e então outra nova instância classifica o ponto de âncora na terceira rodada, após o qual o processo continua.
![Explicação detalhada do framework Shoal: Como reduzir a latência do Bullshark na Aptos?])https://img-cdn.gateio.im/webp-social/moments-0b0928cb6240e994c1514c75e080a4b2.webp(
Reputação dos Líderes
Durante a ordenação Bullshark, ao pular pontos de ancoragem, a latência aumenta. Nesse caso, a técnica de pipeline não pode ajudar, pois não é possível iniciar uma nova instância antes da ordenação do ponto de ancoragem da instância anterior. O Shoal garante que é menos provável selecionar o respectivo líder para lidar com os pontos de ancoragem perdidos, atribuindo uma pontuação a cada nó de validação com base no histórico de atividade recente de cada nó de validação, utilizando um mecanismo de reputação. Os validadores que respondem e participam do protocolo receberão altas pontuações, caso contrário, os nós de validação receberão baixas pontuações, pois podem estar em colapso, lentos ou agindo de forma maliciosa.
A sua filosofia é recalcular de forma determinística o mapeamento predefinido F do round para o líder a cada 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 chegar a um consenso sobre a pontuação, de modo a alcançar um consenso sobre a história utilizada para derivar a pontuação.
No Shoal, a reputação de pipeline e liderança pode se combinar naturalmente, pois ambas 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 pontos de ancoragem na r-ésima rodada, os validadores precisam apenas calcular um novo mapeamento F' a partir da r+1-ésima rodada com base na história causal dos pontos de ancoragem ordenados da r-ésima rodada. Em seguida, os nós de validação 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 elas introduzem aumenta o número de estados internos que precisam ser geridos e observados, o que aumenta a complexidade do processo de depuração e requer mais técnicas de observabilidade.
O tempo limite também pode aumentar significativamente a latência, uma vez que é muito importante configurá-los adequadamente e geralmente requer ajustes dinâmicos, pois depende fortemente do ambiente ) rede (. Antes de passar para o próximo líder, o protocolo paga 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 estavam sobrecarregados, e o tempo limite já havia expirado antes de eles avançarem.
Infelizmente, protocolos baseados em líderes ) como Hotstuff e Jolteon( essencialmente requerem um tempo limite, para garantir que o protocolo avance sempre que um líder falhe. Sem um tempo limite, mesmo um líder em colapso pode parar o protocolo indefinidamente. Como não é possível distinguir entre um líder com falhas e um líder lento durante períodos assíncronos, o tempo limite pode levar os nós de validação a observar mudanças em todos os líderes sem a atividade de consenso.
No Bullshark, o tempo limite é utilizado para a construção do DAG, a fim de garantir que durante a sincronização, líderes honestos adicionem pontos de ancoragem.
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.
11 gostos
Recompensa
11
6
Republicar
Partilhar
Comentar
0/400
GateUser-c799715c
· 23h atrás
A melhoria de desempenho está boa~
Ver originalResponder0
AllInAlice
· 08-09 05:29
É uma pessoa dura 40% de redução de latência
Ver originalResponder0
0xSherlock
· 08-09 05:28
latência esta onda consegue lidar é um pouco legal
Ver originalResponder0
BrokenYield
· 08-09 05:27
meh, outra "otimização" que provavelmente criará mais riscos sistêmicos do que resolve... o dinheiro inteligente já está se protegendo contra isso
Otimização do framework Shoal para o consenso DAG, reduzindo significativamente a latência do Bullshark na Aptos.
Otimização do consenso DAG: Como a estrutura Shoal pode reduzir a latência do Bullshark na Aptos
Aptos Labs recentemente resolveu dois importantes problemas abertos no DAG BFT, reduzindo significativamente a latência e eliminando pela primeira vez a necessidade de timeouts em protocolos assíncronos determinísticos. No geral, a estrutura Shoal melhorou a latência do Bullshark em 40% em condições sem falhas e em 80% em condições de falha.
Shoal é um protocolo que melhora o protocolo de consenso baseado em Narwhal ( através de pipelines e da reputação dos líderes, como os frameworks DAG-Rider, Tusk, Bullshark ). O pipeline reduz a latência de ordenação do DAG ao introduzir um ponto de ancoragem a 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 Shoal utilize a construção de DAG assíncrono para eliminar os tempos limite em todos os cenários. Isso permite que Shoal forneça uma responsividade universal, incluindo a responsividade otimista que normalmente é necessária.
A tecnologia do Shoal é relativamente simples, envolvendo a execução em sequência de várias instâncias do protocolo subjacente. Quando instanciamos com Bullshark, obtemos um grupo de "tubarões" que estão participando de uma corrida de revezamento.
Motivação
Ao buscar um alto desempenho em redes de blockchain, as pessoas têm se concentrado na redução da complexidade de comunicação. No entanto, essa abordagem não resultou em um aumento significativo na taxa de transferência. Por exemplo, o Hotstuff implementado nas versões iniciais do Diem alcançou apenas 3500 TPS, muito abaixo da meta de 100k+ TPS.
Recent breakthroughs stem from the realization that data propagation is the main bottleneck based on leader protocols and can benefit from parallelization. The Narwhal system separates data propagation from core Consenso logic, proposing an architecture where all validators propagate data simultaneously, while the consensus component only orders a small amount of metadata. The Narwhal paper reports a throughput of 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 usá-la para escalar o protocolo de consenso atual Jolteon. O Jolteon é um protocolo baseado em líderes, que combina o caminho rápido linear do Tendermint com as mudanças de vista no estilo PBFT, conseguindo reduzir a latência do Hotstuff em 33%. No entanto, os protocolos de consenso baseados em líderes claramente não conseguem aproveitar totalmente o potencial de throughput do Narwhal. Apesar de a propagação de dados estar separada do consenso, com o aumento do throughput, o líder do Hotstuff/Jolteon ainda está limitado.
Assim, decidimos implementar o Bullshark sobre o DAG Narwhal, 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 traz um custo de latência de 50%.
Este artigo apresenta como a Shoal reduziu significativamente a latência do Bullshark.
Contexto DAG-BFT
Cada vértice no DAG do Narwhal está associado a um número de rodada. Para entrar na rodada r, um validador deve primeiro obter n-f vértices que pertencem à rodada r-1. Cada validador pode transmitir um vértice por rodada, e cada vértice deve referenciar pelo menos n-f vértices da rodada anterior. Devido à assíncronia da rede, diferentes validadores podem observar diferentes visões locais do DAG em qualquer ponto no tempo.
Uma característica chave do DAG é a não ambiguidade: se dois nós de validação tiverem o mesmo vértice v na visão local do DAG, então eles têm a mesma história causal de v.
Ordem Total
É possível alcançar consenso total sobre 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 existentes baseados em Narwhal têm a seguinte estrutura:
Ponto de ancoragem: a cada algumas rodadas há um líder previamente determinado, cujo vértice é 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 pular.
Ordem da história causal: os validadores processam um por um a lista de âncoras ordenadas, classificando todos os vértices não ordenados anteriores na história causal de cada âncora.
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 esses protocolos:
Todos os validadores concordam com o primeiro ponto âncora ordenado.
Bullshark latência
A latência do Bullshark depende do número de rondas 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 está longe de ser a ideal.
Pergunta 1: latência média do bloco. No Bullshark, cada rodada par tem um ponto âncora, e os vértices da rodada ímpar são interpretados como votos. Em situações comuns, são necessárias duas rodadas de DAG para classificar os pontos âncora, no entanto, os vértices na história causal dos pontos âncora precisam de mais rodadas para serem classificados. Normalmente, 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: Situação de falha de latência. Se o líder de uma rodada não conseguir transmitir rapidamente o ponto de ancoragem, não será possível classificar o ponto de ancoragem (, portanto, será ignorado ), todos os vértices não classificados das rodadas anteriores devem aguardar que o próximo ponto de ancoragem seja classificado. Isso pode 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 melhorou o Bullshark( ou qualquer outro protocolo BFT baseado em Narwhal) através de uma linha de montagem, permitindo que haja um ponto de ancoragem a cada rodada e reduzindo a latência de todos os vértices não ancorados no DAG para três rodadas. Shoal também introduziu um mecanismo de reputação de líder sem custo no DAG, fazendo 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, pelas seguintes razões:
As tentativas anteriores de modificar a lógica central do Bullshark parecem ser essencialmente impossíveis.
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 do ancla no Bullshark (. Embora a divergência na identidade do líder não viole a segurança desses protocolos, pode resultar em ordenações completamente diferentes no Bullshark, o que traz à tona o núcleo do problema: escolher anclas de roda de forma dinâmica e determinística é necessário para resolver o consenso, e os validadores precisam concordar sobre a história ordenada para escolher futuros anclas.
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 solução está escondida na simplicidade.
No Shoal, confiamos na capacidade de executar cálculos locais sobre o DAG e implementamos a capacidade de armazenar e reinterpretar informações de rodadas anteriores. Com todas as validações concordando com a principal percepção do primeiro ponto âncora ordenado, Shoal combina sequencialmente várias instâncias de Bullshark para processamento em pipeline, tornando ) o primeiro ponto âncora ordenado como o ponto de troca das instâncias, e ( 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(
Linha de Produção
V que mapeia a rodada para o líder. O Shoal executa instâncias do Bullshark uma após a outra, de modo que para cada instância, o âncora é previamente determinado pelo mapeamento F. Cada instância classifica um âncora, acionando a mudança para a próxima instância.
Inicialmente, o Shoal lançou a primeira instância do Bullshark na primeira rodada do DAG e funcionou até que o primeiro ponto de ancoragem ordenado fosse determinado, como na rodada r. Todos os validadores concordaram com este ponto de ancoragem. Assim, todos os validadores puderam concordar com segurança em reinterpretar o DAG a partir da rodada r+1. O Shoal simplesmente lançou uma nova instância do Bullshark na rodada r+1.
No melhor cenário, isso permite que o Shoal classifique um âncora a 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 sua vez possui um ponto de âncora, esse âncora é classificado por essa instância, e então outra nova instância classifica o ponto de âncora na terceira rodada, após o qual o processo continua.
![Explicação detalhada do framework Shoal: Como reduzir a latência do Bullshark na Aptos?])https://img-cdn.gateio.im/webp-social/moments-0b0928cb6240e994c1514c75e080a4b2.webp(
Reputação dos Líderes
Durante a ordenação Bullshark, ao pular pontos de ancoragem, a latência aumenta. Nesse caso, a técnica de pipeline não pode ajudar, pois não é possível iniciar uma nova instância antes da ordenação do ponto de ancoragem da instância anterior. O Shoal garante que é menos provável selecionar o respectivo líder para lidar com os pontos de ancoragem perdidos, atribuindo uma pontuação a cada nó de validação com base no histórico de atividade recente de cada nó de validação, utilizando um mecanismo de reputação. Os validadores que respondem e participam do protocolo receberão altas pontuações, caso contrário, os nós de validação receberão baixas pontuações, pois podem estar em colapso, lentos ou agindo de forma maliciosa.
A sua filosofia é recalcular de forma determinística o mapeamento predefinido F do round para o líder a cada 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 chegar a um consenso sobre a pontuação, de modo a alcançar um consenso sobre a história utilizada para derivar a pontuação.
No Shoal, a reputação de pipeline e liderança pode se combinar naturalmente, pois ambas 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 pontos de ancoragem na r-ésima rodada, os validadores precisam apenas calcular um novo mapeamento F' a partir da r+1-ésima rodada com base na história causal dos pontos de ancoragem ordenados da r-ésima rodada. Em seguida, os nós de validação 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 latência？])https://img-cdn.gateio.im/webp-social/moments-859e732e16c3eee0e2c93422474debc2.webp(
Não há mais tempo limite
O tempo limite desempenha um papel crucial em todas as implementações BFT determinísticas baseadas em líderes. No entanto, a complexidade que elas introduzem aumenta o número de estados internos que precisam ser geridos e observados, o que aumenta a complexidade do processo de depuração e requer mais técnicas de observabilidade.
O tempo limite também pode aumentar significativamente a latência, uma vez que é muito importante configurá-los adequadamente e geralmente requer ajustes dinâmicos, pois depende fortemente do ambiente ) rede (. Antes de passar para o próximo líder, o protocolo paga 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 estavam sobrecarregados, e o tempo limite já havia expirado antes de eles avançarem.
Infelizmente, protocolos baseados em líderes ) como Hotstuff e Jolteon( essencialmente requerem um tempo limite, para garantir que o protocolo avance sempre que um líder falhe. Sem um tempo limite, mesmo um líder em colapso pode parar o protocolo indefinidamente. Como não é possível distinguir entre um líder com falhas e um líder lento durante períodos assíncronos, o tempo limite pode levar os nós de validação a observar mudanças em todos os líderes sem a atividade de consenso.
No Bullshark, o tempo limite é utilizado para a construção do DAG, a fim de garantir que durante a sincronização, líderes honestos adicionem pontos de ancoragem.