Estrutura Shoal: Como Gota a latência do Bullshark em Aptos
Aptos Labs resolveu dois importantes problemas abertos no DAG BFT, reduzindo significativamente a Gota, e eliminou pela primeira vez a necessidade de timeouts em protocolos práticos determinísticos. No geral, melhorou a latência do Bullshark em 40% em caso de operação sem falhas e em 80% em caso de falhas.
Shoal é uma estrutura que, através de um pipeline e da reputação dos líderes, melhora qualquer protocolo de consenso baseado em Narwhal ( como DAG-Rider, Tusk, Bullshark ). O pipeline reduz a Gota de ordenação do DAG ao introduzir âncoras em cada rodada, enquanto a reputação do líder melhora ainda mais o problema de latência, garantindo que as âncoras estejam associadas aos nós de verificação mais rápidos. Além disso, a reputação do líder permite que o Shoal utilize a construção de DAG assíncrona para eliminar os tempos limite em todos os cenários. Isso permite que o Shoal forneça propriedades de resposta universal, incluindo a resposta otimista geralmente necessária.
Esta tecnologia é muito simples, envolvendo a execução em sequência de múltiplas instâncias do protocolo subjacente. Assim, ao instanciar o Bullshark, obtemos um grupo de "tubarões" que estão a realizar uma corrida de estafetas.
Fundo
Na busca por alto desempenho em redes blockchain, as pessoas sempre se concentraram na Gota da complexidade de comunicação. No entanto, esse método não resultou em um aumento significativo na taxa de transferência. Por exemplo, o Hotstuff implementado na versão inicial do Diem alcançou apenas 3500 TPS, muito abaixo da meta de 100k+ TPS.
A recente quebra de paradigma decorre da percepção de que a propagação de dados é o principal gargalo baseado no protocolo de líderes, podendo beneficiar-se da paralelização. O sistema Narwhal separa a propagação de dados da lógica de consenso central, propondo que todos os validadores propaguem dados simultaneamente, enquanto o componente de consenso apenas ordena uma quantidade reduzida de metadados. O artigo do Narwhal reportou uma capacidade de 160.000 TPS.
O Quorum Store apresentado anteriormente é a implementação do Narwhal, que separa a propagação de dados do consenso, utilizado 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 vista ao estilo PBFT, reduzindo a latência do Hotstuff em 33%. No entanto, o protocolo de consenso baseado em líder não consegue aproveitar plenamente o potencial de throughput do Narwhal.
Portanto, foi decidido implantar o Bullshark sobre o DAG Narwhal, que é um protocolo de consenso com zero custo de comunicação. Infelizmente, a estrutura DAG que suporta o Bullshark, com alta taxa de transferência, traz um custo de latência de 50% em comparação com o Jolteon.
Este artigo apresenta como o Shoal pode reduzir significativamente a latência do Bullshark.
Fundo DAG-BFT
Cada vértice no DAG do Narwhal está associado a uma rodada. Para entrar na rodada r, um validador deve primeiro 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 à assíncronia da rede, diferentes validadores podem observar diferentes visões locais do DAG em qualquer momento.
Uma característica chave do DAG é a não ambiguidade: se dois nós de validação têm 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 custos de comunicação adicionais. Para isso, 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.
Todos os protocolos de consenso baseados em Narwhal existentes têm a seguinte estrutura:
Ponto de ancoragem: a cada algumas rodadas há um líder previamente determinado, o pico do líder é chamado de ponto de ancoragem.
Pontos de anclagem de ordenação: os validadores decidem de forma independente, mas determinística, quais pontos de anclagem ordenar e quais pular.
História causal ordenada: os validadores processam uma lista de âncoras ordenadas um após o outro, ordenando todos os vértices anteriores desordenados na história causal de cada âncora de acordo com regras de determinismo.
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. Shoal faz 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 de ancoragem ordenados no DAG. Embora algumas versões de sincronização tenham uma latência melhor do que as versões assíncronas, ainda estão longe do ideal.
Pergunta 1: latência média do bloco. Em Bullshark, há um ponto âncora em cada rodada par, e os vértices da rodada ímpar são interpretados como votos. Normalmente, são necessárias duas rodadas de DAG para ordenar os pontos âncora; no entanto, os vértices na história causal do ponto âncora precisam de mais rodadas para esperar pela ordenação do ponto âncora. Normalmente, os vértices da rodada ímpar precisam de três rodadas, enquanto os vértices não âncoras da rodada par precisam de quatro rodadas.
Problema 2: Latência de casos de falha. Se um líder de rodada não conseguir transmitir rapidamente o ponto âncora, não será possível classificar o ponto âncora ( que foi pulado ), todos os vértices não classificados das rodadas anteriores devem aguardar a classificação do próximo ponto âncora. Isso diminui significativamente o desempenho da rede de replicação geográfica, especialmente porque o Bullshark usa um tempo limite para aguardar o líder.
Framework Shoal
Shoal melhora o Bullshark( ou qualquer outro protocolo BFT baseado em Narwhal) através de uma linha de montagem, permitindo pontos âncora em cada rodada, reduzindo a latência de todos os vértices não âncora no DAG para três rodadas. Shoal também introduz um mecanismo de reputação de líder de zero custo no DAG, favorecendo a escolha de 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, na essência, impossíveis.
A reputação dos líderes é introduzida no DiemBFT e formalizada no Carousel, selecionando dinamicamente os futuros líderes com base no desempenho passado dos validadores no âncora do Bullshark (. Embora divergências na identidade do líder não violem a segurança desses protocolos, isso pode levar a uma ordenação completamente diferente no Bullshark, o que levanta o cerne da questão: a seleção dinâmica de âncoras é necessária para resolver o consenso, e os validadores precisam chegar a um consenso sobre a história ordenada para escolher as âncoras futuras.
Como evidência da dificuldade do problema, a implementação do Bullshark ) inclui ( atualmente no ambiente de produção que não suporta essas características.
Protocolo
A Shoal depende da capacidade de realizar cálculos locais em DAG para implementar a capacidade de salvar e reinterpretar informações das rodadas anteriores. Com todos os validadores concordando com a percepção do primeiro âncora ordenada, a Shoal combina sequencialmente várias instâncias de Bullshark para processamento em pipeline, tornando ) o primeiro âncora ordenada o ponto de mudança de instância, ( a história causal do âncora é usada para calcular a reputação do líder.
) linha de fluxo
V que mapeia rodadas para líderes. Shoal executa instâncias do Bullshark uma após a outra, onde cada âncora da instância é determinada previamente pelo mapeamento F. Cada instância encomenda uma âncora, acionando a transição 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 esse ponto de ancoragem. Assim, todos os validadores podem concordar de forma conclusiva em reinterpretar o DAG a partir da rodada r+1. O Shoal apenas iniciou uma nova instância do Bullshark na rodada r+1.
No melhor dos casos, isso permite que o Shoal encomende um âncora por rodada. O ponto de âncora da primeira rodada é ordenado pela primeira instância. Em seguida, o Shoal começa uma nova instância na segunda rodada, que por sua vez tem um ponto de âncora, que é ordenado por essa instância, e então outra nova instância encomenda o ponto de âncora na terceira rodada, e o processo continua.
reputação de líder
Quando um ponto de ancoragem é ignorado durante a ordenação Bullshark, a latência aumenta. Nessa situação, o pipeline não pode fazer nada, pois não é possível iniciar uma nova instância antes que o ponto de ancoragem da instância anterior seja encomendado. O Shoal garante que líderes correspondentes que lidam com pontos de ancoragem perdidos sejam menos propensos a serem escolhidos no futuro, atribuindo pontuações com base no histórico de atividades recentes de cada nó de validação através de um mecanismo de reputação. Validadores que respondem e participam do protocolo recebem altas pontuações, caso contrário, recebem baixas pontuações, pois podem falhar, ser lentos ou agir de maneira maliciosa.
A sua filosofia é recalcular de forma determinística o mapeamento predefinido F de rodadas para líderes sempre que houver uma atualização de pontuação, favorecendo os líderes com pontuações mais altas. Para que os validadores cheguem a um consenso sobre o novo mapeamento, eles devem alcançar um consenso sobre a pontuação, estabelecendo assim um consenso sobre a história usada para derivar a pontuação.
Em Shoal, o pipeline e a reputação de liderança podem se combinar naturalmente, pois ambos utilizam a mesma tecnologia central, que é reinterpretar o DAG após alcançar um consenso sobre o primeiro ponto âncora ordenado.
A única diferença é que, após a ordenação dos pontos âncora na r-ésima rodada, o validador só precisa calcular um novo mapeamento F' a partir da r+1-ésima rodada com base na história causal dos pontos âncora 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 âncora atualizada F' para executar uma nova instância do Bullshark a partir da r+1-ésima rodada.
sem tempo limite
O tempo limite desempenha um papel crucial em todas as implementações BFT determinísticas baseadas em líder. No entanto, a complexidade que elas introduzem aumenta o número de estados internos que precisam ser geridos e monitorizados, aumentando a complexidade de depuração e exigindo mais técnicas de observabilidade.
O tempo limite também aumentará significativamente a latência, pois é importante configurá-los corretamente, geralmente requerendo ajustes dinâmicos, dependendo muito do ambiente ( rede ). Antes de transferir para o próximo líder, o protocolo pagará a penalização completa do tempo limite para os líderes com falha. Portanto, as configurações de tempo limite não podem ser excessivamente conservadoras, mas se forem muito curtas, o protocolo pode pular bons líderes. Por exemplo, observamos que sob alta carga, os líderes em Jolteon/Hotstuff ficam sobrecarregados, e o tempo limite já expirou antes que o progresso pudesse ser feito.
Infelizmente, protocolos baseados em líderes ### como Hotstuff e Jolteon( essencialmente requerem Gota, para garantir que o protocolo possa progredir a cada falha do líder. Sem Gota, mesmo um líder que falhou pode parar o protocolo para sempre. Como não é possível distinguir entre um líder falho e um líder lento durante o período assíncrono, Gota pode levar os nós de validação a mudarem todos os líderes sem uma atividade de consenso.
No Bullshark, o tempo limite é utilizado na construção do DAG, para garantir que durante a sincronização, os líderes honestos adicionem âncoras ao DAG rapidamente para ordenação.
Observamos que a construção DAG fornece um "relógio" para estimar a velocidade da rede. Na ausência de pausas, enquanto n-f validadores honestos continuarem a adicionar vértices ao DAG, as rodadas continuarão a avançar. Embora o Bullshark possa não ser capaz de classificar a ) devido a problemas de liderança (, o DAG ainda cresce a velocidade da rede, apesar de alguns líderes terem problemas ou a rede estar assíncrona. No final, quando líderes sem falhas transmitirem rapidamente âncoras, toda a história causal das âncoras será classificada.
Na nossa avaliação, comparou-se se o Bullshark teve ou não latência nas seguintes situações:
Líder Rápido: pelo menos mais rápido que os outros validadores. Os dois métodos oferecem a mesma latência, pois o anexo é ordenado e não utiliza tempos limites.
Líderes Errados: Bullshark sem tempo limite proporciona melhor latência, pois os nós de validação pulam imediatamente.
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.
10 gostos
Recompensa
10
4
Republicar
Partilhar
Comentar
0/400
HashRateHermit
· 5h atrás
latência melhorada em 80%? Que onda de bull!
Ver originalResponder0
SelfRugger
· 5h atrás
80% latência reduzida, o Marquês também gritou bull.
Ver originalResponder0
CommunitySlacker
· 5h atrás
bull cerveja latência otimizou 80%
Ver originalResponder0
Hash_Bandit
· 5h atrás
caramba, isto é como quando otimizamos a dificuldade de mineração de btc em 2013... grandes ganhos de taxa de hash fr
Estrutura Shoal: Otimização de latência Bullshark no Aptos
Estrutura Shoal: Como Gota a latência do Bullshark em Aptos
Aptos Labs resolveu dois importantes problemas abertos no DAG BFT, reduzindo significativamente a Gota, e eliminou pela primeira vez a necessidade de timeouts em protocolos práticos determinísticos. No geral, melhorou a latência do Bullshark em 40% em caso de operação sem falhas e em 80% em caso de falhas.
Shoal é uma estrutura que, através de um pipeline e da reputação dos líderes, melhora qualquer protocolo de consenso baseado em Narwhal ( como DAG-Rider, Tusk, Bullshark ). O pipeline reduz a Gota de ordenação do DAG ao introduzir âncoras em cada rodada, enquanto a reputação do líder melhora ainda mais o problema de latência, garantindo que as âncoras estejam associadas aos nós de verificação mais rápidos. Além disso, a reputação do líder permite que o Shoal utilize a construção de DAG assíncrona para eliminar os tempos limite em todos os cenários. Isso permite que o Shoal forneça propriedades de resposta universal, incluindo a resposta otimista geralmente necessária.
Esta tecnologia é muito simples, envolvendo a execução em sequência de múltiplas instâncias do protocolo subjacente. Assim, ao instanciar o Bullshark, obtemos um grupo de "tubarões" que estão a realizar uma corrida de estafetas.
Fundo
Na busca por alto desempenho em redes blockchain, as pessoas sempre se concentraram na Gota da complexidade de comunicação. No entanto, esse método não resultou em um aumento significativo na taxa de transferência. Por exemplo, o Hotstuff implementado na versão inicial do Diem alcançou apenas 3500 TPS, muito abaixo da meta de 100k+ TPS.
A recente quebra de paradigma decorre da percepção de que a propagação de dados é o principal gargalo baseado no protocolo de líderes, podendo beneficiar-se da paralelização. O sistema Narwhal separa a propagação de dados da lógica de consenso central, propondo que todos os validadores propaguem dados simultaneamente, enquanto o componente de consenso apenas ordena uma quantidade reduzida de metadados. O artigo do Narwhal reportou uma capacidade de 160.000 TPS.
O Quorum Store apresentado anteriormente é a implementação do Narwhal, que separa a propagação de dados do consenso, utilizado 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 vista ao estilo PBFT, reduzindo a latência do Hotstuff em 33%. No entanto, o protocolo de consenso baseado em líder não consegue aproveitar plenamente o potencial de throughput do Narwhal.
Portanto, foi decidido implantar o Bullshark sobre o DAG Narwhal, que é um protocolo de consenso com zero custo de comunicação. Infelizmente, a estrutura DAG que suporta o Bullshark, com alta taxa de transferência, traz um custo de latência de 50% em comparação com o Jolteon.
Este artigo apresenta como o Shoal pode reduzir significativamente a latência do Bullshark.
Fundo DAG-BFT
Cada vértice no DAG do Narwhal está associado a uma rodada. Para entrar na rodada r, um validador deve primeiro 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 à assíncronia da rede, diferentes validadores podem observar diferentes visões locais do DAG em qualquer momento.
Uma característica chave do DAG é a não ambiguidade: se dois nós de validação têm 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 custos de comunicação adicionais. Para isso, 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.
Todos os protocolos de consenso baseados em Narwhal existentes têm a seguinte estrutura:
Ponto de ancoragem: a cada algumas rodadas há um líder previamente determinado, o pico do líder é chamado de ponto de ancoragem.
Pontos de anclagem de ordenação: os validadores decidem de forma independente, mas determinística, quais pontos de anclagem ordenar e quais pular.
História causal ordenada: os validadores processam uma lista de âncoras ordenadas um após o outro, ordenando todos os vértices anteriores desordenados na história causal de cada âncora de acordo com regras de determinismo.
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. Shoal faz 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 de ancoragem ordenados no DAG. Embora algumas versões de sincronização tenham uma latência melhor do que as versões assíncronas, ainda estão longe do ideal.
Pergunta 1: latência média do bloco. Em Bullshark, há um ponto âncora em cada rodada par, e os vértices da rodada ímpar são interpretados como votos. Normalmente, são necessárias duas rodadas de DAG para ordenar os pontos âncora; no entanto, os vértices na história causal do ponto âncora precisam de mais rodadas para esperar pela ordenação do ponto âncora. Normalmente, os vértices da rodada ímpar precisam de três rodadas, enquanto os vértices não âncoras da rodada par precisam de quatro rodadas.
Problema 2: Latência de casos de falha. Se um líder de rodada não conseguir transmitir rapidamente o ponto âncora, não será possível classificar o ponto âncora ( que foi pulado ), todos os vértices não classificados das rodadas anteriores devem aguardar a classificação do próximo ponto âncora. Isso diminui significativamente o desempenho da rede de replicação geográfica, especialmente porque o Bullshark usa um tempo limite para aguardar o líder.
Framework Shoal
Shoal melhora o Bullshark( ou qualquer outro protocolo BFT baseado em Narwhal) através de uma linha de montagem, permitindo pontos âncora em cada rodada, reduzindo a latência de todos os vértices não âncora no DAG para três rodadas. Shoal também introduz um mecanismo de reputação de líder de zero custo no DAG, favorecendo a escolha de 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, na essência, impossíveis.
A reputação dos líderes é introduzida no DiemBFT e formalizada no Carousel, selecionando dinamicamente os futuros líderes com base no desempenho passado dos validadores no âncora do Bullshark (. Embora divergências na identidade do líder não violem a segurança desses protocolos, isso pode levar a uma ordenação completamente diferente no Bullshark, o que levanta o cerne da questão: a seleção dinâmica de âncoras é necessária para resolver o consenso, e os validadores precisam chegar a um consenso sobre a história ordenada para escolher as âncoras futuras.
Como evidência da dificuldade do problema, a implementação do Bullshark ) inclui ( atualmente no ambiente de produção que não suporta essas características.
Protocolo
A Shoal depende da capacidade de realizar cálculos locais em DAG para implementar a capacidade de salvar e reinterpretar informações das rodadas anteriores. Com todos os validadores concordando com a percepção do primeiro âncora ordenada, a Shoal combina sequencialmente várias instâncias de Bullshark para processamento em pipeline, tornando ) o primeiro âncora ordenada o ponto de mudança de instância, ( a história causal do âncora é usada para calcular a reputação do líder.
) linha de fluxo
V que mapeia rodadas para líderes. Shoal executa instâncias do Bullshark uma após a outra, onde cada âncora da instância é determinada previamente pelo mapeamento F. Cada instância encomenda uma âncora, acionando a transição 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 esse ponto de ancoragem. Assim, todos os validadores podem concordar de forma conclusiva em reinterpretar o DAG a partir da rodada r+1. O Shoal apenas iniciou uma nova instância do Bullshark na rodada r+1.
No melhor dos casos, isso permite que o Shoal encomende um âncora por rodada. O ponto de âncora da primeira rodada é ordenado pela primeira instância. Em seguida, o Shoal começa uma nova instância na segunda rodada, que por sua vez tem um ponto de âncora, que é ordenado por essa instância, e então outra nova instância encomenda o ponto de âncora na terceira rodada, e o processo continua.
reputação de líder
Quando um ponto de ancoragem é ignorado durante a ordenação Bullshark, a latência aumenta. Nessa situação, o pipeline não pode fazer nada, pois não é possível iniciar uma nova instância antes que o ponto de ancoragem da instância anterior seja encomendado. O Shoal garante que líderes correspondentes que lidam com pontos de ancoragem perdidos sejam menos propensos a serem escolhidos no futuro, atribuindo pontuações com base no histórico de atividades recentes de cada nó de validação através de um mecanismo de reputação. Validadores que respondem e participam do protocolo recebem altas pontuações, caso contrário, recebem baixas pontuações, pois podem falhar, ser lentos ou agir de maneira maliciosa.
A sua filosofia é recalcular de forma determinística o mapeamento predefinido F de rodadas para líderes sempre que houver uma atualização de pontuação, favorecendo os líderes com pontuações mais altas. Para que os validadores cheguem a um consenso sobre o novo mapeamento, eles devem alcançar um consenso sobre a pontuação, estabelecendo assim um consenso sobre a história usada para derivar a pontuação.
Em Shoal, o pipeline e a reputação de liderança podem se combinar naturalmente, pois ambos utilizam a mesma tecnologia central, que é reinterpretar o DAG após alcançar um consenso sobre o primeiro ponto âncora ordenado.
A única diferença é que, após a ordenação dos pontos âncora na r-ésima rodada, o validador só precisa calcular um novo mapeamento F' a partir da r+1-ésima rodada com base na história causal dos pontos âncora 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 âncora atualizada F' para executar uma nova instância do Bullshark a partir da r+1-ésima rodada.
sem tempo limite
O tempo limite desempenha um papel crucial em todas as implementações BFT determinísticas baseadas em líder. No entanto, a complexidade que elas introduzem aumenta o número de estados internos que precisam ser geridos e monitorizados, aumentando a complexidade de depuração e exigindo mais técnicas de observabilidade.
O tempo limite também aumentará significativamente a latência, pois é importante configurá-los corretamente, geralmente requerendo ajustes dinâmicos, dependendo muito do ambiente ( rede ). Antes de transferir para o próximo líder, o protocolo pagará a penalização completa do tempo limite para os líderes com falha. Portanto, as configurações de tempo limite não podem ser excessivamente conservadoras, mas se forem muito curtas, o protocolo pode pular bons líderes. Por exemplo, observamos que sob alta carga, os líderes em Jolteon/Hotstuff ficam sobrecarregados, e o tempo limite já expirou antes que o progresso pudesse ser feito.
Infelizmente, protocolos baseados em líderes ### como Hotstuff e Jolteon( essencialmente requerem Gota, para garantir que o protocolo possa progredir a cada falha do líder. Sem Gota, mesmo um líder que falhou pode parar o protocolo para sempre. Como não é possível distinguir entre um líder falho e um líder lento durante o período assíncrono, Gota pode levar os nós de validação a mudarem todos os líderes sem uma atividade de consenso.
No Bullshark, o tempo limite é utilizado na construção do DAG, para garantir que durante a sincronização, os líderes honestos adicionem âncoras ao DAG rapidamente para ordenação.
Observamos que a construção DAG fornece um "relógio" para estimar a velocidade da rede. Na ausência de pausas, enquanto n-f validadores honestos continuarem a adicionar vértices ao DAG, as rodadas continuarão a avançar. Embora o Bullshark possa não ser capaz de classificar a ) devido a problemas de liderança (, o DAG ainda cresce a velocidade da rede, apesar de alguns líderes terem problemas ou a rede estar assíncrona. No final, quando líderes sem falhas transmitirem rapidamente âncoras, toda a história causal das âncoras será classificada.
Na nossa avaliação, comparou-se se o Bullshark teve ou não latência nas seguintes situações:
Líder Rápido: pelo menos mais rápido que os outros validadores. Os dois métodos oferecem a mesma latência, pois o anexo é ordenado e não utiliza tempos limites.
Líderes Errados: Bullshark sem tempo limite proporciona melhor latência, pois os nós de validação pulam imediatamente.