Estrutura Shoal: Como 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 tempo limite em protocolos de consenso 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 melhora o protocolo de consenso baseado em Narwhal ( através de processamento em pipeline e um mecanismo de reputação dos líderes, como DAG-Rider, Tusk, Bullshark ). O processamento em pipeline reduz a latência de ordenação do DAG ao introduzir um ponto de ancoragem a cada rodada, enquanto o mecanismo de reputação dos líderes melhora ainda mais o problema de latência ao garantir que o ponto de ancoragem esteja associado ao nó de validação mais rápido. Além disso, a reputação dos líderes permite que o Shoal utilize a construção de DAGs assíncronos para eliminar timeouts em todos os cenários. Isso permite que o Shoal ofereça características de resposta universal, incluindo a resposta otimista geralmente necessária.
A tecnologia é muito simples, envolvendo a execução em sequência de várias instâncias do protocolo subjacente. Assim, ao instanciar o Bullshark, obtemos um grupo de "tubarões" que estão em uma corrida de revezamento.
Contexto
Na busca por alto desempenho em redes de blockchain, as pessoas sempre se concentraram em reduzir a complexidade da comunicação. No entanto, essa abordagem não trouxe 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 100000+ TPS.
As recentes quebras de paradigma surgiram da compreensã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 central de consenso, propondo uma arquitetura onde todos os validadores propagam dados simultaneamente, enquanto o componente de consenso apenas ordena uma pequena quantidade de metadados. O artigo do Narwhal relatou uma taxa de transferência de 160.000 TPS.
Aptos anteriormente apresentou o Quorum Store, que é a implementação do Narwhal, separando a propagação de dados do consenso, e como utilizá-lo para escalar o protocolo de consenso atual Jolteon. Jolteon é um protocolo baseado em líder que combina o caminho linear rápido do Tendermint com as mudanças de vista ao estilo PBFT, podendo reduzir a latência do Hotstuff em 33%. No entanto, os protocolos de consenso baseados em líder claramente não conseguem aproveitar plenamente o potencial de throughput do Narwhal. Embora a propagação de dados e o consenso estejam separados, à medida que o throughput aumenta, o líder do Hotstuff/Jolteon ainda enfrenta limitações.
Assim, a Aptos decidiu implementar o Bullshark sobre o Narwhal DAG, que é um protocolo de consenso com zero custo de comunicação. Infelizmente, em comparação com o Jolteon, a estrutura DAG que suporta o Bullshark de alta capacidade de processamento trouxe um custo de latência de 50%.
Este artigo apresenta como o Shoal reduz significativamente a latência do Bullshark.
Fundo do DAG-BFT
Cada vértice no DAG de Narwhal está associado a uma rodada. Para entrar na rodada r, o validador deve primeiro obter n-f vértices pertencentes à rodada r-1. Cada validador pode transmitir um vértice por rodada, e cada vértice deve referenciar pelo menos n-f vértices da rodada anterior. Devido à assíncronia da rede, diferentes validadores podem observar diferentes visões locais do DAG em qualquer ponto no tempo.
Uma propriedade chave do DAG é a univocidade: 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.
Prefácio
É possível alcançar consenso sobre a ordem total de todos os vértices no DAG sem custos de comunicação adicionais. Para isso, os validadores no DAG-Rider, Tusk e Bullshark interpretam a estrutura do DAG como um protocolo de consenso, onde os vértices representam propostas e as arestas representam votos.
Embora a lógica de interseção de grupos na estrutura DAG seja diferente, todos os protocolos de consenso baseados em Narwhal existentes têm a seguinte estrutura:
Ponto de âncora pré-definido: a cada algumas rodadas (, por exemplo, em Bullshark, a cada duas rodadas ) haverá um líder pré-determinado, cujo pico é chamado de ponto de âncora.
Pontos de Ancoragem de Ordenação: os validadores decidem de forma independente, mas determinística, quais pontos de ancoragem ordenar e quais pular.
História causal ordenada: os validadores processam um a um a sua lista de âncoras ordenadas, e para cada âncora, ordenam todos os vértices anteriores não ordenados em sua história causal através de algumas regras determinísticas.
A chave para garantir a segurança é assegurar que, no passo (2), todos os nós de validação honestos criem uma lista de âncoras ordenadas, de modo que todas as listas compartilhem o mesmo prefixo. No Shoal, faz-se a seguinte observação sobre todos os protocolos acima mencionados:
Todos os validadores concordam com o primeiro ponto de âncora ordenado.
Bullshark latência
A latência do Bullshark depende do número de rodadas entre os pontos âncora ordenados no DAG. Embora a versão síncrona do Bullshark seja mais prática e tenha melhor latência do que a versão assíncrona, ainda está longe de ser a ideal.
Pergunta 1: latência média de bloco. No Bullshark, cada rodada par tem um ponto de ancoragem, 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 de ancoragem; no entanto, os vértices na história causal dos pontos de ancoragem precisam de mais rodadas para esperar que os pontos de ancoragem sejam ordenados. Em casos comuns, os vértices na rodada ímpar precisam de três rodadas, enquanto os vértices não ancorados na rodada par precisam de quatro rodadas.
Questão 2: Caso de falha de latência. A análise de latência acima se aplica a situações sem falha; por outro lado, se o líder de uma rodada não conseguir transmitir o âncora rapidamente o suficiente, não será possível classificar o âncora (, portanto, será pulado ), e todos os vértices não classificados nas rodadas anteriores devem aguardar até que o próximo âncora seja classificado. Isso pode reduzir significativamente o desempenho da rede de replicação geográfica, especialmente porque o Bullshark usa timeouts para aguardar o líder.
Estrutura Shoal
Shoal resolveu esses dois problemas de latência, melhorando o Bullshark( ou qualquer outro protocolo BFT baseado em Narwhal) através do processamento em pipeline, permitindo que haja um ponto de ancoragem em cada rodada e reduzindo a latência de todos os vértices não âncora no DAG para três rodadas. Shoal também introduziu um mecanismo de reputação de líder sem custo no DAG, o que faz com que a seleção favoreça 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 processamento em linha de alterar a lógica central do Bullshark parecem, por sua essência, ser impossíveis.
A reputação dos líderes é introduzida no DiemBFT e formalizada no Carousel, sendo selecionada dinamicamente com base no desempenho passado dos validadores para futuros líderes, a ideia do âncora no Bullshark (. Embora a divergência na identidade dos líderes não viole a segurança desses protocolos, no Bullshark, isso pode levar a ordenações completamente diferentes, o que levanta o cerne da questão, ou seja, a seleção dinâmica e determinística dos âncoras de rodada é necessária para resolver o consenso, e os validadores precisam concordar sobre a história ordenada para escolher as futuras âncoras.
Como evidência da dificuldade do problema, a implementação do Bullshark, incluindo a implementação atualmente em ambiente de produção, não suporta essas características.
Protocolo
Apesar dos desafios mencionados, a solução está escondida na simplicidade.
No Shoal, dependemos da capacidade de executar cálculos locais sobre o DAG e implementamos a capacidade de armazenar e reinterpretar as informações das rodadas anteriores. Com a visão central de que todos os validadores concordam com o primeiro ponto de âncora ordenado, o Shoal combina sequencialmente várias instâncias de Bullshark para processá-las em pipeline, tornando ) o primeiro ponto de âncora ordenado o ponto de mudança das instâncias, bem como ( a história causal do ponto de âncora utilizada 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 a rodada ao líder. Shoal executa instâncias do Bullshark uma a uma, de modo que para cada instância, a âncora é previamente determinada pelo mapeamento F. Cada instância ordena uma âncora, o que desencadeia 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 a executou 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 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. A âncora da primeira rodada é classificada pela primeira instância. Em seguida, o Shoal inicia uma nova instância na segunda rodada, que por sua vez tem uma âncora, que é classificada por essa instância, e então, outra nova instância classifica a âncora na terceira rodada, e o processo continua.
![Explicação detalhada do Shoal: Como reduzir a latência do Bullshark na Aptos?])https://img-cdn.gateio.im/webp-social/moments-0b0928cb6240e994c1514c75e080a4b2.webp(
Reputação do Líder
Ao pular âncoras durante a ordenação Bullshark, a latência aumenta. Nesse caso, a técnica de processamento em pipeline é impotente, pois não é possível iniciar novas instâncias antes que a âncora da instância anterior seja ordenada. O Shoal assegura que é menos provável escolher futuros líderes para processar âncoras perdidas, atribuindo uma pontuação a cada nó de validação com base na história da atividade recente de cada nó de validação por meio de um mecanismo de reputação. Os validadores que respondem e participam do protocolo receberão pontuações altas, caso contrário, os nós de validação serão atribuídos a pontuações baixas, pois podem estar em falha, lentos ou agir de forma maliciosa.
A sua filosofia é recalcular de forma determinística o mapeamento pré-definido F do turno ao 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, eles devem chegar a um consenso sobre a pontuação, alcançando assim um consenso sobre a história usada 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 chegar a um 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 apenas precisam calcular um novo mapeamento F' a partir da r+1ª rodada, com base na história causal das âncoras ordenadas na r-ésima rodada. Em seguida, os nós validadores começam a executar uma nova instância do Bullshark a partir da r+1ª rodada, usando a função de seleção de âncoras atualizada F'.
![Análise detalhada do framework Shoal: como reduzir a latência do Bullshark na Aptos?])https://img-cdn.gateio.im/webp-social/moments-859e732e16c3eee0e2c93422474debc2.webp(
Sem mais tempo de espera
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 aumentará significativamente a latência, pois é muito importante configurá-los adequadamente, e geralmente é necessário ajustá-los dinamicamente, pois depende fortemente do ambiente ) rede (. Antes de passar para o próximo líder, o protocolo pagará a penalização completa do tempo limite para o líder com falha. Portanto, a configuração do tempo limite não pode ser excessivamente conservadora, mas se o tempo limite for muito curto, o protocolo pode ignorar bons líderes. Por exemplo, observamos que, em situações de alta carga, os líderes no Jolteon/Hotstuff estão sobrecarregados e o tempo limite já expirou antes que eles pudessem avançar.
Infelizmente, com base no protocolo do líder ) como
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.
9 gostos
Recompensa
9
5
Partilhar
Comentar
0/400
ChainSpy
· 7h atrás
Verde! APT vai Até à lua
Ver originalResponder0
AirdropHunter007
· 18h atrás
latência reduzida em 40%? Até à lua!
Ver originalResponder0
BTCBeliefStation
· 18h atrás
fantástico Esta melhoria deixou-me de boca aberta
Ver originalResponder0
CounterIndicator
· 18h atrás
bull ah latência caiu mais da metade
Ver originalResponder0
MoonRocketTeam
· 18h atrás
Ai, a latência caiu 50% diretamente. Esta janela de lançamento vai até à lua.
Otimização do quadro Shoal para o protocolo de consenso Aptos, a latência do Bullshark foi significativamente reduzida.
Estrutura Shoal: Como 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 tempo limite em protocolos de consenso 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 melhora o protocolo de consenso baseado em Narwhal ( através de processamento em pipeline e um mecanismo de reputação dos líderes, como DAG-Rider, Tusk, Bullshark ). O processamento em pipeline reduz a latência de ordenação do DAG ao introduzir um ponto de ancoragem a cada rodada, enquanto o mecanismo de reputação dos líderes melhora ainda mais o problema de latência ao garantir que o ponto de ancoragem esteja associado ao nó de validação mais rápido. Além disso, a reputação dos líderes permite que o Shoal utilize a construção de DAGs assíncronos para eliminar timeouts em todos os cenários. Isso permite que o Shoal ofereça características de resposta universal, incluindo a resposta otimista geralmente necessária.
A tecnologia é muito simples, envolvendo a execução em sequência de várias instâncias do protocolo subjacente. Assim, ao instanciar o Bullshark, obtemos um grupo de "tubarões" que estão em uma corrida de revezamento.
Contexto
Na busca por alto desempenho em redes de blockchain, as pessoas sempre se concentraram em reduzir a complexidade da comunicação. No entanto, essa abordagem não trouxe 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 100000+ TPS.
As recentes quebras de paradigma surgiram da compreensã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 central de consenso, propondo uma arquitetura onde todos os validadores propagam dados simultaneamente, enquanto o componente de consenso apenas ordena uma pequena quantidade de metadados. O artigo do Narwhal relatou uma taxa de transferência de 160.000 TPS.
Aptos anteriormente apresentou o Quorum Store, que é a implementação do Narwhal, separando a propagação de dados do consenso, e como utilizá-lo para escalar o protocolo de consenso atual Jolteon. Jolteon é um protocolo baseado em líder que combina o caminho linear rápido do Tendermint com as mudanças de vista ao estilo PBFT, podendo reduzir a latência do Hotstuff em 33%. No entanto, os protocolos de consenso baseados em líder claramente não conseguem aproveitar plenamente o potencial de throughput do Narwhal. Embora a propagação de dados e o consenso estejam separados, à medida que o throughput aumenta, o líder do Hotstuff/Jolteon ainda enfrenta limitações.
Assim, a Aptos decidiu implementar o Bullshark sobre o Narwhal DAG, que é um protocolo de consenso com zero custo de comunicação. Infelizmente, em comparação com o Jolteon, a estrutura DAG que suporta o Bullshark de alta capacidade de processamento trouxe um custo de latência de 50%.
Este artigo apresenta como o Shoal reduz significativamente a latência do Bullshark.
Fundo do DAG-BFT
Cada vértice no DAG de Narwhal está associado a uma rodada. Para entrar na rodada r, o validador deve primeiro obter n-f vértices pertencentes à rodada r-1. Cada validador pode transmitir um vértice por rodada, e cada vértice deve referenciar pelo menos n-f vértices da rodada anterior. Devido à assíncronia da rede, diferentes validadores podem observar diferentes visões locais do DAG em qualquer ponto no tempo.
Uma propriedade chave do DAG é a univocidade: 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.
Prefácio
É possível alcançar consenso sobre a ordem total de todos os vértices no DAG sem custos de comunicação adicionais. Para isso, os validadores no DAG-Rider, Tusk e Bullshark interpretam a estrutura do DAG como um protocolo de consenso, onde os vértices representam propostas e as arestas representam votos.
Embora a lógica de interseção de grupos na estrutura DAG seja diferente, todos os protocolos de consenso baseados em Narwhal existentes têm a seguinte estrutura:
Ponto de âncora pré-definido: a cada algumas rodadas (, por exemplo, em Bullshark, a cada duas rodadas ) haverá um líder pré-determinado, cujo pico é chamado de ponto de âncora.
Pontos de Ancoragem de Ordenação: os validadores decidem de forma independente, mas determinística, quais pontos de ancoragem ordenar e quais pular.
História causal ordenada: os validadores processam um a um a sua lista de âncoras ordenadas, e para cada âncora, ordenam todos os vértices anteriores não ordenados em sua história causal através de algumas regras determinísticas.
A chave para garantir a segurança é assegurar que, no passo (2), todos os nós de validação honestos criem uma lista de âncoras ordenadas, de modo que todas as listas compartilhem o mesmo prefixo. No Shoal, faz-se a seguinte observação sobre todos os protocolos acima mencionados:
Todos os validadores concordam com o primeiro ponto de âncora ordenado.
Bullshark latência
A latência do Bullshark depende do número de rodadas entre os pontos âncora ordenados no DAG. Embora a versão síncrona do Bullshark seja mais prática e tenha melhor latência do que a versão assíncrona, ainda está longe de ser a ideal.
Pergunta 1: latência média de bloco. No Bullshark, cada rodada par tem um ponto de ancoragem, 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 de ancoragem; no entanto, os vértices na história causal dos pontos de ancoragem precisam de mais rodadas para esperar que os pontos de ancoragem sejam ordenados. Em casos comuns, os vértices na rodada ímpar precisam de três rodadas, enquanto os vértices não ancorados na rodada par precisam de quatro rodadas.
Questão 2: Caso de falha de latência. A análise de latência acima se aplica a situações sem falha; por outro lado, se o líder de uma rodada não conseguir transmitir o âncora rapidamente o suficiente, não será possível classificar o âncora (, portanto, será pulado ), e todos os vértices não classificados nas rodadas anteriores devem aguardar até que o próximo âncora seja classificado. Isso pode reduzir significativamente o desempenho da rede de replicação geográfica, especialmente porque o Bullshark usa timeouts para aguardar o líder.
Estrutura Shoal
Shoal resolveu esses dois problemas de latência, melhorando o Bullshark( ou qualquer outro protocolo BFT baseado em Narwhal) através do processamento em pipeline, permitindo que haja um ponto de ancoragem em cada rodada e reduzindo a latência de todos os vértices não âncora no DAG para três rodadas. Shoal também introduziu um mecanismo de reputação de líder sem custo no DAG, o que faz com que a seleção favoreça 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 processamento em linha de alterar a lógica central do Bullshark parecem, por sua essência, ser impossíveis.
A reputação dos líderes é introduzida no DiemBFT e formalizada no Carousel, sendo selecionada dinamicamente com base no desempenho passado dos validadores para futuros líderes, a ideia do âncora no Bullshark (. Embora a divergência na identidade dos líderes não viole a segurança desses protocolos, no Bullshark, isso pode levar a ordenações completamente diferentes, o que levanta o cerne da questão, ou seja, a seleção dinâmica e determinística dos âncoras de rodada é necessária para resolver o consenso, e os validadores precisam concordar sobre a história ordenada para escolher as futuras âncoras.
Como evidência da dificuldade do problema, a implementação do Bullshark, incluindo a implementação atualmente em ambiente de produção, não suporta essas características.
Protocolo
Apesar dos desafios mencionados, a solução está escondida na simplicidade.
No Shoal, dependemos da capacidade de executar cálculos locais sobre o DAG e implementamos a capacidade de armazenar e reinterpretar as informações das rodadas anteriores. Com a visão central de que todos os validadores concordam com o primeiro ponto de âncora ordenado, o Shoal combina sequencialmente várias instâncias de Bullshark para processá-las em pipeline, tornando ) o primeiro ponto de âncora ordenado o ponto de mudança das instâncias, bem como ( a história causal do ponto de âncora utilizada 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 a rodada ao líder. Shoal executa instâncias do Bullshark uma a uma, de modo que para cada instância, a âncora é previamente determinada pelo mapeamento F. Cada instância ordena uma âncora, o que desencadeia 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 a executou 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 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. A âncora da primeira rodada é classificada pela primeira instância. Em seguida, o Shoal inicia uma nova instância na segunda rodada, que por sua vez tem uma âncora, que é classificada por essa instância, e então, outra nova instância classifica a âncora na terceira rodada, e o processo continua.
![Explicação detalhada do Shoal: Como reduzir a latência do Bullshark na Aptos?])https://img-cdn.gateio.im/webp-social/moments-0b0928cb6240e994c1514c75e080a4b2.webp(
Reputação do Líder
Ao pular âncoras durante a ordenação Bullshark, a latência aumenta. Nesse caso, a técnica de processamento em pipeline é impotente, pois não é possível iniciar novas instâncias antes que a âncora da instância anterior seja ordenada. O Shoal assegura que é menos provável escolher futuros líderes para processar âncoras perdidas, atribuindo uma pontuação a cada nó de validação com base na história da atividade recente de cada nó de validação por meio de um mecanismo de reputação. Os validadores que respondem e participam do protocolo receberão pontuações altas, caso contrário, os nós de validação serão atribuídos a pontuações baixas, pois podem estar em falha, lentos ou agir de forma maliciosa.
A sua filosofia é recalcular de forma determinística o mapeamento pré-definido F do turno ao 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, eles devem chegar a um consenso sobre a pontuação, alcançando assim um consenso sobre a história usada 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 chegar a um 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 apenas precisam calcular um novo mapeamento F' a partir da r+1ª rodada, com base na história causal das âncoras ordenadas na r-ésima rodada. Em seguida, os nós validadores começam a executar uma nova instância do Bullshark a partir da r+1ª rodada, usando a função de seleção de âncoras atualizada F'.
![Análise detalhada do framework Shoal: como reduzir a latência do Bullshark na Aptos?])https://img-cdn.gateio.im/webp-social/moments-859e732e16c3eee0e2c93422474debc2.webp(
Sem mais tempo de espera
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 aumentará significativamente a latência, pois é muito importante configurá-los adequadamente, e geralmente é necessário ajustá-los dinamicamente, pois depende fortemente do ambiente ) rede (. Antes de passar para o próximo líder, o protocolo pagará a penalização completa do tempo limite para o líder com falha. Portanto, a configuração do tempo limite não pode ser excessivamente conservadora, mas se o tempo limite for muito curto, o protocolo pode ignorar bons líderes. Por exemplo, observamos que, em situações de alta carga, os líderes no Jolteon/Hotstuff estão sobrecarregados e o tempo limite já expirou antes que eles pudessem avançar.
Infelizmente, com base no protocolo do líder ) como