Reduzindo a latência do Bullshark no Aptos: Uma explicação do framework Shoal
Aptos labs resolveu dois importantes problemas abertos no DAG BFT, reduzindo significativamente a latência e eliminando pela primeira vez a necessidade de pausas em protocolos práticos determinísticos. No geral, em situações sem falhas, a latência do Bullshark foi melhorada em 40%, enquanto em situações de falha foi melhorada em 80%.
O framework Shoal melhora o protocolo de consenso baseado em Narwhal ( como DAG-Rider, Tusk, Bullshark ) através de pipeline e mecanismo de reputação do líder. O pipeline introduz um ponto âncora a cada rodada para reduzir a latência de ordenação do DAG, enquanto a reputação do líder garante que o ponto âncora esteja associado ao nó de validação mais rápido, melhorando ainda mais a latência. Além disso, a reputação do líder permite que o Shoal utilize a construção de DAG assíncrona para eliminar timeouts em todos os cenários, resultando em uma propriedade de resposta universal.
A tecnologia do Shoal é muito simples, executando várias instâncias do protocolo subjacente em ordem. Quando instanciado com Bullshark, é como um grupo de "tubarões" participando de uma corrida de revezamento.
Contexto
Na busca por alto desempenho de redes blockchain, as pessoas sempre se preocuparam em reduzir a complexidade da comunicação, mas isso não resultou em um aumento significativo na taxa de transferência. Por exemplo, o Hotstuff implementado no early Diem alcançou apenas 3500 TPS, bem abaixo da meta de 100k+ TPS.
Recent breakthroughs stem from recognizing that data dissemination is the main bottleneck based on leader protocols, which can benefit from parallelization. The Narwhal system separates data dissemination from core consensus logic, with all validators disseminating data simultaneously, and the consensus component only ordering a small amount of metadata. The Narwhal paper reported a throughput of 160,000 TPS.
Aptos anteriormente apresentou o Quorum Store, que é a implementação Narwhal, separando a propagação de dados do consenso e sendo utilizado para escalar o atual protocolo de consenso Jolteon. Jolteon combina o caminho rápido linear do Tendermint com a alteração de vista no estilo PBFT, reduzindo a latência do Hotstuff em 33%. No entanto, os protocolos de consenso baseados em líderes não conseguem aproveitar plenamente o potencial de throughput do Narwhal.
Assim, a Aptos decidiu implementar o Bullshark, um protocolo de consenso com zero custo de comunicação, sobre o DAG Narwhal. Infelizmente, a estrutura DAG que suporta a alta taxa de transferência do Bullshark trouxe um custo de latência de 50%.
Este artigo apresenta como o Shoal reduz significativamente a latência do Bullshark.
Contexto DAG-BFT
Cada vértice no DAG do Narwhal está relacionado a um número de rodada. Ao entrar na rodada r, os validadores devem obter n-f vértices da rodada r-1. Cada validador pode transmitir um vértice por rodada, e cada vértice deve referenciar pelo menos n-f vértices da rodada anterior. Devido à assimetria da rede, diferentes validadores podem observar diferentes visões locais do DAG.
Uma propriedade chave do DAG é que não é ambígua: 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.
Sequência Geral
É possível alcançar consenso sobre a ordem total de todos os vértices no DAG sem custos adicionais de comunicação. Os validadores em DAG-Rider, Tusk e Bullshark interpretam a estrutura do DAG como um protocolo de consenso, onde os vértices representam propostas e as arestas representam votos.
Embora a lógica de interseção de grupos na estrutura DAG seja diferente, todos os protocolos de consenso baseados em Narwhal têm a seguinte estrutura:
Ponto de ancoragem: a cada algumas rodadas, há um líder pré-determinado, cujo pico é chamado de ponto de ancoragem.
Pontos de ancoragem de classificação: os validadores decidem de forma independente, mas determinística, quais pontos de ancoragem classificar e quais ignorar.
História causal ordenada: os validadores processam um por um a lista de âncoras ordenadas, ordenando os vértices desordenados 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, observamos que:
Todos os validadores concordam com o primeiro ponto de ancoragem ordenado.
Bullshark Atraso
O atraso do Bullshark depende do número de voltas entre os pontos de ancoragem ordenados no DAG. Algumas versões de sincronização têm um atraso melhor do que as versões assíncronas, mas ainda não são ideais.
Questão 1: Atraso médio de bloco. No Bullshark, cada rodada par tem um ponto âncora, e os vértices da rodada ímpar são interpretados como votos. Em casos comuns, são necessárias duas rodadas de DAG para ordenar os pontos âncora, mas os vértices na história causal dos pontos âncora precisam de mais rodadas para aguardar a ordenação dos pontos âncora. Em casos comuns, os vértices da rodada ímpar precisam de três rodadas, e os vértices não âncora da rodada par precisam de quatro rodadas.
Questão 2: Atraso na situação de falha. Se um líder de rodada não conseguir transmitir o ponto de ancoragem a tempo, não será possível ordená-lo ( será pulado ), todos os vértices não ordenados das rodadas anteriores devem aguardar que o próximo ponto de ancoragem seja ordenado. Isso reduz significativamente o desempenho da rede de replicação geográfica, especialmente porque o Bullshark usa o tempo limite para aguardar o líder.
Estrutura Shoal
Shoal melhora o Bullshark( ou qualquer protocolo BFT baseado em Narwhal) através de uma linha de produção, permitindo que haja um ponto de ancoragem em cada rodada, reduzindo a latência de todos os vértices não ancorados no DAG para três rodadas. Shoal também introduz um mecanismo de reputação de líder sem custo no DAG, favorecendo a escolha de líderes rápidos.
desafio
No 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 na linha de produção parecem, na essência, impossíveis.
A reputação dos líderes é introduzida no DiemBFT e formalizada no Carousel, escolhendo dinamicamente os futuros líderes com base no desempenho passado dos validadores ( âncora no Bullshark ). Embora a divergência na identidade do líder não comprometa a segurança desses protocolos, ela pode levar a uma ordenação completamente diferente no Bullshark, levantando a questão central: escolher âncoras de roda de forma dinâmica e determinística é necessário para resolver o consenso, e os validadores precisam chegar a um consenso sobre a história ordenada para escolher futuras âncoras.
Como evidência da dificuldade do problema, a implementação do Bullshark (, incluindo ) no ambiente de produção atual, não suporta essas características.
Acordo
Apesar dos desafios acima mencionados, a solução está escondida na simplicidade.
A Shoal depende da capacidade de executar cálculos locais sobre o DAG, permitindo a preservação e reinterpretação das informações das rodadas anteriores. Com base no consenso de todos os validadores sobre a primeira âncora ordenada, a Shoal combina sequencialmente várias instâncias de Bullshark para processamento em pipeline, fazendo com que ( a primeira âncora ordenada seja o ponto de transição das instâncias, ) a história causal da âncora é utilizada para calcular a reputação do líder.
( linha de montagem
V que mapeia as rodadas para os líderes. O Shoal executa instâncias do Bullshark em ordem, com cada âncora da instância previamente determinada pelo mapeamento F. Cada instância ordena uma âncora, acionando a transição para a próxima instância.
No início, Shoal lançou a primeira instância do Bullshark na primeira rodada do DAG, funcionando até que o primeiro ponto de ancoragem ordenado ) fosse determinado como a rodada r ###. Todos os validadores concordaram com esse ponto de ancoragem, portanto, pode-se concordar com segurança em reinterpretar o DAG a partir da rodada r+1. Shoal lançou uma nova instância do Bullshark na rodada r+1.
No melhor cenário, isso permite que o Shoal classifique um âncora por rodada. O ponto de âncora da primeira rodada é classificado pela primeira instância. Depois, o Shoal inicia uma nova instância na segunda rodada, que tem seu próprio ponto de âncora e é classificada por essa instância, e então outra nova instância classifica o ponto de âncora na terceira rodada, e assim por diante.
( Credibilidade do líder
Quando a classificação do Bullshark ignora os pontos de âncora, o atraso aumenta. Nessa situação, a pipeline não pode fazer nada, pois não é possível iniciar novas instâncias antes do ponto de âncora da instância anterior ser classificado. O Shoal atribui pontuações a cada nó de validação através de um mecanismo de reputação, garantindo que, com base no seu histórico de atividades recentes, seja menos provável que líderes correspondentes sejam escolhidos no futuro para lidar com os pontos de âncora perdidos. Validadores que respondem e participam do protocolo recebem altas pontuações, caso contrário, recebem pontuações baixas ) podem falhar, ser lentos ou agir de forma maliciosa ###.
A ideia é recalcular de forma determinística o mapeamento predefinido F do round ao líder a cada atualização de pontuação, favorecendo os líderes de alta pontuação. Para que os validadores cheguem a um consenso sobre o novo mapeamento, eles devem alcançar um consenso sobre a pontuação, assim conseguindo um consenso sobre a história utilizada para derivar a pontuação.
No Shoal, a linha de montagem e a reputação do líder se combinam naturalmente, pois utilizam a mesma tecnologia central: reinterpretar o DAG após concordar com o primeiro ponto âncora ordenado.
A única diferença é que, após a âncora de ordenação da rodada r, os validadores calculam uma nova mapeamento F' a partir da rodada r+1 com base na história causal das âncoras ordenadas da rodada r. 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 é necessário mais tempo de espera
O tempo limite é 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, aumentando a complexidade do processo de depuração e exigindo mais técnicas de observabilidade.
O tempo limite também aumenta significativamente a latência, pois é importante configurá-los adequadamente, geralmente exigindo ajustes dinâmicos, dependendo muito do ambiente ) rede ###. Antes de mudar para o próximo líder, o protocolo paga a penalidade completa de latência de tempo limite para o líder com falha. Portanto, as configurações de tempo limite não podem ser muito conservadoras, mas se forem muito curtas, o protocolo pode pular um bom líder. Por exemplo, observamos que sob alta carga, os líderes no Jolteon/Hotstuff ficam sobrecarregados, e o tempo limite já expira antes que o progresso seja feito.
Infelizmente, os protocolos baseados em líderes (, como Hotstuff e Jolteon ), essencialmente exigem timeouts para garantir que o protocolo avance sempre que um líder falhar. Sem timeouts, até mesmo líderes que falharam podem parar o protocolo indefinidamente. Como não é possível distinguir entre líderes com falha e lentos durante períodos assíncronos, os timeouts podem levar os nós de validação a ver as mudanças em todos os líderes sem atividade de consenso.
No Bullshark, o tempo limite é usado para a construção do DAG, para garantir que durante a sincronização os líderes honestos adicionem pontos de âncora ao DAG a uma velocidade rápida o suficiente para que possam ser ordenados.
Observamos que a construção do DAG fornece um "relógio" para estimar a velocidade da rede. Sem pausas, contanto que n-f validadores honestos continuem a adicionar vértices ao DAG, os turnos continuarão avançando. Embora o Bullshark possa não conseguir ordenar ( na velocidade da rede devido a problemas de liderança ), o DAG ainda cresce na velocidade da rede, apesar de alguns líderes terem problemas ou a rede estar assíncrona. No final, quando líderes sem falhas broadcastarem âncoras rapidamente o suficiente, toda a história causal das âncoras será ordenada.
Em avaliação, comparamos se o Bullshark teve ou não tempo limite nas seguintes situações:
Líderes rápidos, pelo menos mais rápidos do que outros validadores. Nesse caso, os dois métodos oferecem a mesma latência, pois os âncoras são ordenados e não utilizam timeouts.
Líderes errados, neste caso, o Bullshark sem pausa oferece uma melhor latência, pois os nós de validação irão imediatamente pular seu ponto de ancoragem, enquanto os validadores com pausa irão esperar até que eles expirem antes de continuar.
Líderes lentos, esta é a única situação em que o Bullshark tem um desempenho melhor em termos de tempo. Pois sem pausas, os pontos de ancoragem podem ser ignorados, pois o líder não consegue transmiti-los rapidamente o suficiente, enquanto com pausas, os validadores irão esperar pelos pontos de ancoragem.
Em Shoal, evitar o tempo limite está intimamente relacionado com a reputação do líder. Espera repetida.
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.
15 gostos
Recompensa
15
7
Partilhar
Comentar
0/400
MEVictim
· 9h atrás
A otimização melhorou significativamente a eficiência.
Aptos introduz a estrutura Shoal, Gota a latência do Bullshark e elimina a necessidade de tempo limite.
Reduzindo a latência do Bullshark no Aptos: Uma explicação do framework Shoal
Aptos labs resolveu dois importantes problemas abertos no DAG BFT, reduzindo significativamente a latência e eliminando pela primeira vez a necessidade de pausas em protocolos práticos determinísticos. No geral, em situações sem falhas, a latência do Bullshark foi melhorada em 40%, enquanto em situações de falha foi melhorada em 80%.
O framework Shoal melhora o protocolo de consenso baseado em Narwhal ( como DAG-Rider, Tusk, Bullshark ) através de pipeline e mecanismo de reputação do líder. O pipeline introduz um ponto âncora a cada rodada para reduzir a latência de ordenação do DAG, enquanto a reputação do líder garante que o ponto âncora esteja associado ao nó de validação mais rápido, melhorando ainda mais a latência. Além disso, a reputação do líder permite que o Shoal utilize a construção de DAG assíncrona para eliminar timeouts em todos os cenários, resultando em uma propriedade de resposta universal.
A tecnologia do Shoal é muito simples, executando várias instâncias do protocolo subjacente em ordem. Quando instanciado com Bullshark, é como um grupo de "tubarões" participando de uma corrida de revezamento.
Contexto
Na busca por alto desempenho de redes blockchain, as pessoas sempre se preocuparam em reduzir a complexidade da comunicação, mas isso não resultou em um aumento significativo na taxa de transferência. Por exemplo, o Hotstuff implementado no early Diem alcançou apenas 3500 TPS, bem abaixo da meta de 100k+ TPS.
Recent breakthroughs stem from recognizing that data dissemination is the main bottleneck based on leader protocols, which can benefit from parallelization. The Narwhal system separates data dissemination from core consensus logic, with all validators disseminating data simultaneously, and the consensus component only ordering a small amount of metadata. The Narwhal paper reported a throughput of 160,000 TPS.
Aptos anteriormente apresentou o Quorum Store, que é a implementação Narwhal, separando a propagação de dados do consenso e sendo utilizado para escalar o atual protocolo de consenso Jolteon. Jolteon combina o caminho rápido linear do Tendermint com a alteração de vista no estilo PBFT, reduzindo a latência do Hotstuff em 33%. No entanto, os protocolos de consenso baseados em líderes não conseguem aproveitar plenamente o potencial de throughput do Narwhal.
Assim, a Aptos decidiu implementar o Bullshark, um protocolo de consenso com zero custo de comunicação, sobre o DAG Narwhal. Infelizmente, a estrutura DAG que suporta a alta taxa de transferência do Bullshark trouxe um custo de latência de 50%.
Este artigo apresenta como o Shoal reduz significativamente a latência do Bullshark.
Contexto DAG-BFT
Cada vértice no DAG do Narwhal está relacionado a um número de rodada. Ao entrar na rodada r, os validadores devem obter n-f vértices da rodada r-1. Cada validador pode transmitir um vértice por rodada, e cada vértice deve referenciar pelo menos n-f vértices da rodada anterior. Devido à assimetria da rede, diferentes validadores podem observar diferentes visões locais do DAG.
Uma propriedade chave do DAG é que não é ambígua: 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.
Sequência Geral
É possível alcançar consenso sobre a ordem total de todos os vértices no DAG sem custos adicionais de comunicação. Os validadores em DAG-Rider, Tusk e Bullshark interpretam a estrutura do DAG como um protocolo de consenso, onde os vértices representam propostas e as arestas representam votos.
Embora a lógica de interseção de grupos na estrutura DAG seja diferente, todos os protocolos de consenso baseados em Narwhal têm a seguinte estrutura:
Ponto de ancoragem: a cada algumas rodadas, há um líder pré-determinado, cujo pico é chamado de ponto de ancoragem.
Pontos de ancoragem de classificação: os validadores decidem de forma independente, mas determinística, quais pontos de ancoragem classificar e quais ignorar.
História causal ordenada: os validadores processam um por um a lista de âncoras ordenadas, ordenando os vértices desordenados 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, observamos que:
Todos os validadores concordam com o primeiro ponto de ancoragem ordenado.
Bullshark Atraso
O atraso do Bullshark depende do número de voltas entre os pontos de ancoragem ordenados no DAG. Algumas versões de sincronização têm um atraso melhor do que as versões assíncronas, mas ainda não são ideais.
Questão 1: Atraso médio de bloco. No Bullshark, cada rodada par tem um ponto âncora, e os vértices da rodada ímpar são interpretados como votos. Em casos comuns, são necessárias duas rodadas de DAG para ordenar os pontos âncora, mas os vértices na história causal dos pontos âncora precisam de mais rodadas para aguardar a ordenação dos pontos âncora. Em casos comuns, os vértices da rodada ímpar precisam de três rodadas, e os vértices não âncora da rodada par precisam de quatro rodadas.
Questão 2: Atraso na situação de falha. Se um líder de rodada não conseguir transmitir o ponto de ancoragem a tempo, não será possível ordená-lo ( será pulado ), todos os vértices não ordenados das rodadas anteriores devem aguardar que o próximo ponto de ancoragem seja ordenado. Isso reduz significativamente o desempenho da rede de replicação geográfica, especialmente porque o Bullshark usa o tempo limite para aguardar o líder.
Estrutura Shoal
Shoal melhora o Bullshark( ou qualquer protocolo BFT baseado em Narwhal) através de uma linha de produção, permitindo que haja um ponto de ancoragem em cada rodada, reduzindo a latência de todos os vértices não ancorados no DAG para três rodadas. Shoal também introduz um mecanismo de reputação de líder sem custo no DAG, favorecendo a escolha de líderes rápidos.
desafio
No 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 na linha de produção parecem, na essência, impossíveis.
A reputação dos líderes é introduzida no DiemBFT e formalizada no Carousel, escolhendo dinamicamente os futuros líderes com base no desempenho passado dos validadores ( âncora no Bullshark ). Embora a divergência na identidade do líder não comprometa a segurança desses protocolos, ela pode levar a uma ordenação completamente diferente no Bullshark, levantando a questão central: escolher âncoras de roda de forma dinâmica e determinística é necessário para resolver o consenso, e os validadores precisam chegar a um consenso sobre a história ordenada para escolher futuras âncoras.
Como evidência da dificuldade do problema, a implementação do Bullshark (, incluindo ) no ambiente de produção atual, não suporta essas características.
Acordo
Apesar dos desafios acima mencionados, a solução está escondida na simplicidade.
A Shoal depende da capacidade de executar cálculos locais sobre o DAG, permitindo a preservação e reinterpretação das informações das rodadas anteriores. Com base no consenso de todos os validadores sobre a primeira âncora ordenada, a Shoal combina sequencialmente várias instâncias de Bullshark para processamento em pipeline, fazendo com que ( a primeira âncora ordenada seja o ponto de transição das instâncias, ) a história causal da âncora é utilizada para calcular a reputação do líder.
( linha de montagem
V que mapeia as rodadas para os líderes. O Shoal executa instâncias do Bullshark em ordem, com cada âncora da instância previamente determinada pelo mapeamento F. Cada instância ordena uma âncora, acionando a transição para a próxima instância.
No início, Shoal lançou a primeira instância do Bullshark na primeira rodada do DAG, funcionando até que o primeiro ponto de ancoragem ordenado ) fosse determinado como a rodada r ###. Todos os validadores concordaram com esse ponto de ancoragem, portanto, pode-se concordar com segurança em reinterpretar o DAG a partir da rodada r+1. Shoal lançou uma nova instância do Bullshark na rodada r+1.
No melhor cenário, isso permite que o Shoal classifique um âncora por rodada. O ponto de âncora da primeira rodada é classificado pela primeira instância. Depois, o Shoal inicia uma nova instância na segunda rodada, que tem seu próprio ponto de âncora e é classificada por essa instância, e então outra nova instância classifica o ponto de âncora na terceira rodada, e assim por diante.
( Credibilidade do líder
Quando a classificação do Bullshark ignora os pontos de âncora, o atraso aumenta. Nessa situação, a pipeline não pode fazer nada, pois não é possível iniciar novas instâncias antes do ponto de âncora da instância anterior ser classificado. O Shoal atribui pontuações a cada nó de validação através de um mecanismo de reputação, garantindo que, com base no seu histórico de atividades recentes, seja menos provável que líderes correspondentes sejam escolhidos no futuro para lidar com os pontos de âncora perdidos. Validadores que respondem e participam do protocolo recebem altas pontuações, caso contrário, recebem pontuações baixas ) podem falhar, ser lentos ou agir de forma maliciosa ###.
A ideia é recalcular de forma determinística o mapeamento predefinido F do round ao líder a cada atualização de pontuação, favorecendo os líderes de alta pontuação. Para que os validadores cheguem a um consenso sobre o novo mapeamento, eles devem alcançar um consenso sobre a pontuação, assim conseguindo um consenso sobre a história utilizada para derivar a pontuação.
No Shoal, a linha de montagem e a reputação do líder se combinam naturalmente, pois utilizam a mesma tecnologia central: reinterpretar o DAG após concordar com o primeiro ponto âncora ordenado.
A única diferença é que, após a âncora de ordenação da rodada r, os validadores calculam uma nova mapeamento F' a partir da rodada r+1 com base na história causal das âncoras ordenadas da rodada r. 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 é necessário mais tempo de espera
O tempo limite é 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, aumentando a complexidade do processo de depuração e exigindo mais técnicas de observabilidade.
O tempo limite também aumenta significativamente a latência, pois é importante configurá-los adequadamente, geralmente exigindo ajustes dinâmicos, dependendo muito do ambiente ) rede ###. Antes de mudar para o próximo líder, o protocolo paga a penalidade completa de latência de tempo limite para o líder com falha. Portanto, as configurações de tempo limite não podem ser muito conservadoras, mas se forem muito curtas, o protocolo pode pular um bom líder. Por exemplo, observamos que sob alta carga, os líderes no Jolteon/Hotstuff ficam sobrecarregados, e o tempo limite já expira antes que o progresso seja feito.
Infelizmente, os protocolos baseados em líderes (, como Hotstuff e Jolteon ), essencialmente exigem timeouts para garantir que o protocolo avance sempre que um líder falhar. Sem timeouts, até mesmo líderes que falharam podem parar o protocolo indefinidamente. Como não é possível distinguir entre líderes com falha e lentos durante períodos assíncronos, os timeouts podem levar os nós de validação a ver as mudanças em todos os líderes sem atividade de consenso.
No Bullshark, o tempo limite é usado para a construção do DAG, para garantir que durante a sincronização os líderes honestos adicionem pontos de âncora ao DAG a uma velocidade rápida o suficiente para que possam ser ordenados.
Observamos que a construção do DAG fornece um "relógio" para estimar a velocidade da rede. Sem pausas, contanto que n-f validadores honestos continuem a adicionar vértices ao DAG, os turnos continuarão avançando. Embora o Bullshark possa não conseguir ordenar ( na velocidade da rede devido a problemas de liderança ), o DAG ainda cresce na velocidade da rede, apesar de alguns líderes terem problemas ou a rede estar assíncrona. No final, quando líderes sem falhas broadcastarem âncoras rapidamente o suficiente, toda a história causal das âncoras será ordenada.
Em avaliação, comparamos se o Bullshark teve ou não tempo limite nas seguintes situações:
Líderes rápidos, pelo menos mais rápidos do que outros validadores. Nesse caso, os dois métodos oferecem a mesma latência, pois os âncoras são ordenados e não utilizam timeouts.
Líderes errados, neste caso, o Bullshark sem pausa oferece uma melhor latência, pois os nós de validação irão imediatamente pular seu ponto de ancoragem, enquanto os validadores com pausa irão esperar até que eles expirem antes de continuar.
Líderes lentos, esta é a única situação em que o Bullshark tem um desempenho melhor em termos de tempo. Pois sem pausas, os pontos de ancoragem podem ser ignorados, pois o líder não consegue transmiti-los rapidamente o suficiente, enquanto com pausas, os validadores irão esperar pelos pontos de ancoragem.
Em Shoal, evitar o tempo limite está intimamente relacionado com a reputação do líder. Espera repetida.