Estrutura Shoal: Gota de latência do Bullshark em Aptos
Aptos Labs recentemente resolveu dois importantes problemas de abertura no DAG BFT, reduzindo significativamente a latência, e pela primeira vez eliminou a necessidade de tempo limite no protocolo prático determinístico. No geral, em casos sem falhas, melhorou a latência do Bullshark em 40%, e em casos de falha, melhorou em 80%.
Shoal é um framework que melhora o protocolo de consenso baseado em Narwhal ( através do processamento em pipeline e do mecanismo de reputação de líderes. 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 de líderes melhora ainda mais o problema de latência ao garantir que os pontos de ancoragem estejam associados aos nós de validação mais rápidos. Além disso, a reputação de líderes permite que o Shoal utilize a construção de DAG assíncrona para eliminar mecanismos de tempo limite em todos os cenários. Isso permite que o Shoal ofereça uma característica que chamamos de "resposta universal", que inclui as propriedades de resposta otimista normalmente necessárias.
A tecnologia do Shoal é muito simples, envolvendo a execução sequencial de várias instâncias do protocolo subjacente. Assim, quando usamos a instância do Bullshark, o efeito que obtemos é como um grupo de "tubarões" participando de uma corrida de revezamento.
![Explicação detalhada do framework Shoal: como reduzir a latência do Bullshark na Aptos?])https://img-cdn.gateio.im/webp-social/moments-8d6acd885bad7b8f911bdce15a7c884f.webp(
Contexto e Motivação
Na busca por um alto desempenho da rede blockchain, as pessoas sempre se preocuparam em Gota a complexidade da comunicação. No entanto, esse método 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 nossa meta de 100.000+ TPS.
A recente quebra de barreiras deve-se à percepção de que a propagação de dados é o principal gargalo baseado nos protocolos dos líderes e que pode beneficiar da paralelização. O sistema Narwhal separa a propagação de dados da lógica de consenso central, propondo uma arquitetura na qual todos os validadores propagam dados simultaneamente, enquanto o componente de consenso apenas ordena uma pequena quantidade de metadados. O artigo do Narwhal reportou uma taxa de transferência de 160.000 TPS.
No artigo anterior, apresentamos o Quorum Store - a nossa implementação do Narwhal, que separa a propagação de dados do consenso, e como o usamos para escalar o protocolo de consenso atual Jolteon. Jolteon é um protocolo baseado em líder que combina o caminho linear rápido do Tendermint e a mudança de vista no estilo PBFT, podendo reduzir a latência do Hotstuff em 33%. No entanto, é evidente que os protocolos de consenso baseados em líder não conseguem aproveitar plenamente o potencial de throughput do Narwhal. Embora a propagação de dados esteja separada do consenso, à medida que o throughput aumenta, o líder do Hotstuff/Jolteon ainda é limitado.
Assim, decidimos implantar o Bullshark sobre o Narwhal DAG - um protocolo de consenso de zero custo de comunicação. Infelizmente, em comparação com o Jolteon, a estrutura DAG que suporta o Bullshark traz um custo de latência de 50%.
Este artigo irá apresentar como a Shoal pode reduzir significativamente a latência do Bullshark.
![Análise detalhada do framework Shoal: como reduzir a latência do Bullshark na Aptos?])https://img-cdn.gateio.im/webp-social/moments-f6b6281c928e3fa7a2412a480c9c1806.webp(
Background do DAG-BFT
Cada vértice no DAG do Narwhal está associado a uma rodada. Para entrar na rodada r, o validador deve primeiro obter n-f vértices 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 das principais características do DAG é a não ambiguidade: se dois nós de validação têm o mesmo vértice v em sua visão local do DAG, então eles têm a mesma história causal de v.
![Explicação detalhada do framework Shoal: como reduzir a latência do Bullshark na Aptos?])https://img-cdn.gateio.im/webp-social/moments-b7ed8888da112bae8d34c0fdb338b138.webp(
Sequência total
É possível alcançar consenso sobre a ordem total de todos os vértices no DAG sem sobrecarga de comunicação adicional. 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 intersecção da população na estrutura DAG seja diferente, todos os protocolos de consenso baseados no Narwhal existentes têm a seguinte estrutura:
Ponto de ancoragem: a cada algumas rodadas ) como nas duas rodadas ( do Bullshark haverá um líder previamente determinado, o pico do líder é chamado de ponto de ancoragem.
Ponto de Ancoragem de Ordenação: os validadores decidem de forma independente, mas determinística, quais pontos de ancoragem ordenar e quais pular.
Ordenação da história causal: os validadores processam um por um a lista de âncoras ordenadas, e para cada âncora, ordenam todos os vértices anteriores não ordenados em sua história causal de acordo com algumas regras determinísticas.
A chave para garantir a segurança é assegurar que, na etapa 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, fazemos as seguintes observações sobre todos os protocolos acima mencionados:
Todos os validadores concordam com o primeiro ponto de âncora ordenado.
![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(
Bullshark latência
A latência do Bullshark depende do número de rodadas entre os âncoras ordenadas no DAG. Embora a versão sincronizada do Bullshark seja mais prática e tenha melhor latência do que a versão assíncrona, ainda está longe de ser ideal.
Pergunta 1: Gota média de bloco. No Bullshark, cada rodada par tem um ponto âncora, enquanto os vértices da rodada ímpar são interpretados como votos. Em situações comuns, são necessárias duas rodadas de DAG para ordenar os pontos âncora; no entanto, os vértices na história causal dos pontos âncora precisam de mais rodadas para esperar a ordenação dos pontos âncora. Em situações comuns, os vértices na rodada ímpar precisam de três rodadas, enquanto os vértices não âncora na rodada par precisam de quatro rodadas.
Questão 2: latência da situação de falha. 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 rapidamente os pontos âncora, não será possível ordenar os pontos âncora ) e, portanto, serão pulados (, resultando em todos os vértices não ordenados das rodadas anteriores tendo que aguardar que o próximo ponto âncora seja ordenado. Isso pode Gota significativamente o desempenho da rede de replicação geográfica, especialmente porque o Bullshark utiliza timeouts para aguardar o líder.
Shoal resolveu esses dois problemas de latência, melhorando o Bullshark) ou qualquer outro protocolo BFT baseado em Narwhal( através de processamento em pipeline, permitindo que haja um ponto de âncora 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 tendencie 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, pelas seguintes razões:
As tentativas anteriores de processamento em linha tentaram modificar a lógica central do Bullshark, mas isso parece ser essencialmente impossível.
A reputação do líder é introduzida no DiemBFT e formalizada no Carousel, sendo escolhida dinamicamente com base no desempenho passado dos validadores para os pontos de âncora no Bullshark ). Embora a divergência na identidade do líder não viole a segurança desses protocolos, no Bullshark, isso pode levar a ordenações completamente diferentes, levantando o cerne da questão, ou seja, a escolha dinâmica e determinística dos âncoras de rodada é necessária para resolver o consenso, e os validadores precisam concordar sobre o histórico ordenado para escolher os futuros pontos de âncora.
Como evidência da dificuldade do problema, notamos que a implementação do Bullshark, incluindo a atualmente em produção, não suporta essas características.
Protocolo
Apesar dos desafios mencionados, a verdade é que 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 as informações das rodadas anteriores. Com a percepção central de que todos os validadores concordam sobre o primeiro ponto de ancoragem ordenado, o Shoal combina sequencialmente várias instâncias de Bullshark para processá-las em pipeline, onde ( o primeiro ponto de ancoragem ordenado é o ponto de mudança das instâncias, e ) a história causal do ponto de ancoragem é usada para calcular a reputação do líder.
( tratamento em linha de produção
V que mapeia as rodadas aos líderes. O Shoal executa instâncias do Bullshark uma a uma, de modo que para cada instância, o ponto âncora é previamente determinado pelo mapeamento F. Cada instância ordena um ponto âncora, o que desencadeia a transição para a próxima instância.
No início, o Shoal iniciou a primeira instância do Bullshark na primeira rodada do DAG e a executou até determinar o primeiro ponto âncora ordenado, como na rodada r. Todos os validadores concordaram com esse ponto âncora. Assim, todos os validadores podem concordar de forma determinística em reinterpretar o DAG a partir da rodada r+1. O Shoal simplesmente iniciou uma nova instância do Bullshark na rodada r+1.
No melhor cenário, isso permite que o Shoal classifique um ponto âncora em cada rodada. O ponto âncora da primeira rodada é classificado pela primeira instância. Em seguida, o Shoal inicia uma nova instância na segunda rodada, que por si só tem um ponto âncora, e esse ponto âncora é classificado por essa instância, e então, outra nova instância classifica o ponto âncora na terceira rodada, e esse processo continua.
Durante o período de ordenação do Bullshark, a latência aumenta ao pular âncoras. Neste caso, a técnica de processamento em pipeline é impotente, pois não é possível iniciar novas instâncias antes da ordenação da âncora da instância anterior. A Shoal garante que é menos provável que líderes correspondentes sejam escolhidos para lidar com âncoras perdidas no futuro, atribuindo uma pontuação a cada nó de validação com base no histórico da atividade recente de cada nó de validação através de 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 com falhas, lentos ou agindo de forma maliciosa.
A sua filosofia é recalcular de forma determinística o mapeamento predefinido F do round ao líder sempre que a pontuação é 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 utilizada para derivar a pontuação.
No Shoal, o processamento em pipeline e a reputação do líder podem se combinar naturalmente, pois ambos utilizam a mesma tecnologia central, ou seja, reinterpretar o DAG após alcançar consenso sobre o primeiro ponto âncora ordenado.
Na verdade, a única diferença é que, após classificar os âncoras na r-ésima rodada, os validadores apenas precisam calcular um novo mapeamento F' a partir da r+1-ésima rodada, com base na história causal dos âncoras ordenados na r-ésima rodada. Em seguida, os nós de validação começam a usar a função de seleção de âncoras atualizada F' para executar uma nova instância do Bullshark a partir da 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 introduzem aumenta o número de estados internos que precisam ser geridos e monitorizados, o que aumenta a complexidade do processo de depuração e requer mais técnicas de observabilidade.
O tempo de espera também aumentará significativamente a latência.
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
4
Partilhar
Comentar
0/400
ZKProofEnthusiast
· 07-21 04:12
Hmm, levar soal não é tudo subir bastante absurdo.
Ver originalResponder0
SchrodingerWallet
· 07-21 04:10
Esta onda 3 vai até à lua?
Ver originalResponder0
SmartContractPlumber
· 07-21 04:10
A melhoria da camada de consenso é a mais suscetível a riscos em cadeia. Vamos ver se há novas vulnerabilidades.
Ver originalResponder0
DecentralizedElder
· 07-21 04:05
Muito top! Esta latência consegue mesmo chegar a 10%?
Shoal: O novo framework Aptos reduz significativamente a latência do Bullshark, eliminando a necessidade de timeout.
Estrutura Shoal: Gota de latência do Bullshark em Aptos
Aptos Labs recentemente resolveu dois importantes problemas de abertura no DAG BFT, reduzindo significativamente a latência, e pela primeira vez eliminou a necessidade de tempo limite no protocolo prático determinístico. No geral, em casos sem falhas, melhorou a latência do Bullshark em 40%, e em casos de falha, melhorou em 80%.
Shoal é um framework que melhora o protocolo de consenso baseado em Narwhal ( através do processamento em pipeline e do mecanismo de reputação de líderes. 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 de líderes melhora ainda mais o problema de latência ao garantir que os pontos de ancoragem estejam associados aos nós de validação mais rápidos. Além disso, a reputação de líderes permite que o Shoal utilize a construção de DAG assíncrona para eliminar mecanismos de tempo limite em todos os cenários. Isso permite que o Shoal ofereça uma característica que chamamos de "resposta universal", que inclui as propriedades de resposta otimista normalmente necessárias.
A tecnologia do Shoal é muito simples, envolvendo a execução sequencial de várias instâncias do protocolo subjacente. Assim, quando usamos a instância do Bullshark, o efeito que obtemos é como um grupo de "tubarões" participando de uma corrida de revezamento.
![Explicação detalhada do framework Shoal: como reduzir a latência do Bullshark na Aptos?])https://img-cdn.gateio.im/webp-social/moments-8d6acd885bad7b8f911bdce15a7c884f.webp(
Contexto e Motivação
Na busca por um alto desempenho da rede blockchain, as pessoas sempre se preocuparam em Gota a complexidade da comunicação. No entanto, esse método 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 nossa meta de 100.000+ TPS.
A recente quebra de barreiras deve-se à percepção de que a propagação de dados é o principal gargalo baseado nos protocolos dos líderes e que pode beneficiar da paralelização. O sistema Narwhal separa a propagação de dados da lógica de consenso central, propondo uma arquitetura na qual todos os validadores propagam dados simultaneamente, enquanto o componente de consenso apenas ordena uma pequena quantidade de metadados. O artigo do Narwhal reportou uma taxa de transferência de 160.000 TPS.
No artigo anterior, apresentamos o Quorum Store - a nossa implementação do Narwhal, que separa a propagação de dados do consenso, e como o usamos para escalar o protocolo de consenso atual Jolteon. Jolteon é um protocolo baseado em líder que combina o caminho linear rápido do Tendermint e a mudança de vista no estilo PBFT, podendo reduzir a latência do Hotstuff em 33%. No entanto, é evidente que os protocolos de consenso baseados em líder não conseguem aproveitar plenamente o potencial de throughput do Narwhal. Embora a propagação de dados esteja separada do consenso, à medida que o throughput aumenta, o líder do Hotstuff/Jolteon ainda é limitado.
Assim, decidimos implantar o Bullshark sobre o Narwhal DAG - um protocolo de consenso de zero custo de comunicação. Infelizmente, em comparação com o Jolteon, a estrutura DAG que suporta o Bullshark traz um custo de latência de 50%.
Este artigo irá apresentar como a Shoal pode reduzir significativamente a latência do Bullshark.
![Análise detalhada do framework Shoal: como reduzir a latência do Bullshark na Aptos?])https://img-cdn.gateio.im/webp-social/moments-f6b6281c928e3fa7a2412a480c9c1806.webp(
Background do DAG-BFT
Cada vértice no DAG do Narwhal está associado a uma rodada. Para entrar na rodada r, o validador deve primeiro obter n-f vértices 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 das principais características do DAG é a não ambiguidade: se dois nós de validação têm o mesmo vértice v em sua visão local do DAG, então eles têm a mesma história causal de v.
![Explicação detalhada do framework Shoal: como reduzir a latência do Bullshark na Aptos?])https://img-cdn.gateio.im/webp-social/moments-b7ed8888da112bae8d34c0fdb338b138.webp(
Sequência total
É possível alcançar consenso sobre a ordem total de todos os vértices no DAG sem sobrecarga de comunicação adicional. 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 intersecção da população na estrutura DAG seja diferente, todos os protocolos de consenso baseados no Narwhal existentes têm a seguinte estrutura:
Ponto de ancoragem: a cada algumas rodadas ) como nas duas rodadas ( do Bullshark haverá um líder previamente determinado, o pico do líder é chamado de ponto de ancoragem.
Ponto de Ancoragem de Ordenação: os validadores decidem de forma independente, mas determinística, quais pontos de ancoragem ordenar e quais pular.
Ordenação da história causal: os validadores processam um por um a lista de âncoras ordenadas, e para cada âncora, ordenam todos os vértices anteriores não ordenados em sua história causal de acordo com algumas regras determinísticas.
A chave para garantir a segurança é assegurar que, na etapa 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, fazemos as seguintes observações sobre todos os protocolos acima mencionados:
Todos os validadores concordam com o primeiro ponto de âncora ordenado.
![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(
Bullshark latência
A latência do Bullshark depende do número de rodadas entre os âncoras ordenadas no DAG. Embora a versão sincronizada do Bullshark seja mais prática e tenha melhor latência do que a versão assíncrona, ainda está longe de ser ideal.
Pergunta 1: Gota média de bloco. No Bullshark, cada rodada par tem um ponto âncora, enquanto os vértices da rodada ímpar são interpretados como votos. Em situações comuns, são necessárias duas rodadas de DAG para ordenar os pontos âncora; no entanto, os vértices na história causal dos pontos âncora precisam de mais rodadas para esperar a ordenação dos pontos âncora. Em situações comuns, os vértices na rodada ímpar precisam de três rodadas, enquanto os vértices não âncora na rodada par precisam de quatro rodadas.
Questão 2: latência da situação de falha. 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 rapidamente os pontos âncora, não será possível ordenar os pontos âncora ) e, portanto, serão pulados (, resultando em todos os vértices não ordenados das rodadas anteriores tendo que aguardar que o próximo ponto âncora seja ordenado. Isso pode Gota significativamente o desempenho da rede de replicação geográfica, especialmente porque o Bullshark utiliza timeouts para aguardar o líder.
![万字详解Shoal框架：如何减少Aptos上的Bullshark Gota？])https://img-cdn.gateio.im/webp-social/moments-0b0928cb6240e994c1514c75e080a4b2.webp(
Estrutura Shoal
Shoal resolveu esses dois problemas de latência, melhorando o Bullshark) ou qualquer outro protocolo BFT baseado em Narwhal( através de processamento em pipeline, permitindo que haja um ponto de âncora 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 tendencie 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, pelas seguintes razões:
As tentativas anteriores de processamento em linha tentaram modificar a lógica central do Bullshark, mas isso parece ser essencialmente impossível.
A reputação do líder é introduzida no DiemBFT e formalizada no Carousel, sendo escolhida dinamicamente com base no desempenho passado dos validadores para os pontos de âncora no Bullshark ). Embora a divergência na identidade do líder não viole a segurança desses protocolos, no Bullshark, isso pode levar a ordenações completamente diferentes, levantando o cerne da questão, ou seja, a escolha dinâmica e determinística dos âncoras de rodada é necessária para resolver o consenso, e os validadores precisam concordar sobre o histórico ordenado para escolher os futuros pontos de âncora.
Como evidência da dificuldade do problema, notamos que a implementação do Bullshark, incluindo a atualmente em produção, não suporta essas características.
Protocolo
Apesar dos desafios mencionados, a verdade é que 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 as informações das rodadas anteriores. Com a percepção central de que todos os validadores concordam sobre o primeiro ponto de ancoragem ordenado, o Shoal combina sequencialmente várias instâncias de Bullshark para processá-las em pipeline, onde ( o primeiro ponto de ancoragem ordenado é o ponto de mudança das instâncias, e ) a história causal do ponto de ancoragem é usada para calcular a reputação do líder.
( tratamento em linha de produção
V que mapeia as rodadas aos líderes. O Shoal executa instâncias do Bullshark uma a uma, de modo que para cada instância, o ponto âncora é previamente determinado pelo mapeamento F. Cada instância ordena um ponto âncora, o que desencadeia a transição para a próxima instância.
No início, o Shoal iniciou a primeira instância do Bullshark na primeira rodada do DAG e a executou até determinar o primeiro ponto âncora ordenado, como na rodada r. Todos os validadores concordaram com esse ponto âncora. Assim, todos os validadores podem concordar de forma determinística em reinterpretar o DAG a partir da rodada r+1. O Shoal simplesmente iniciou uma nova instância do Bullshark na rodada r+1.
No melhor cenário, isso permite que o Shoal classifique um ponto âncora em cada rodada. O ponto âncora da primeira rodada é classificado pela primeira instância. Em seguida, o Shoal inicia uma nova instância na segunda rodada, que por si só tem um ponto âncora, e esse ponto âncora é classificado por essa instância, e então, outra nova instância classifica o ponto âncora na terceira rodada, e esse processo continua.
![万字详解Shoal框架：如何减少Aptos上的Bullshark Gota？])https://img-cdn.gateio.im/webp-social/moments-9f789cb669f6fcc244ea7ff7648e48b4.webp(
) reputação do líder
Durante o período de ordenação do Bullshark, a latência aumenta ao pular âncoras. Neste caso, a técnica de processamento em pipeline é impotente, pois não é possível iniciar novas instâncias antes da ordenação da âncora da instância anterior. A Shoal garante que é menos provável que líderes correspondentes sejam escolhidos para lidar com âncoras perdidas no futuro, atribuindo uma pontuação a cada nó de validação com base no histórico da atividade recente de cada nó de validação através de 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 com falhas, lentos ou agindo de forma maliciosa.
A sua filosofia é recalcular de forma determinística o mapeamento predefinido F do round ao líder sempre que a pontuação é 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 utilizada para derivar a pontuação.
No Shoal, o processamento em pipeline e a reputação do líder podem se combinar naturalmente, pois ambos utilizam a mesma tecnologia central, ou seja, reinterpretar o DAG após alcançar consenso sobre o primeiro ponto âncora ordenado.
Na verdade, a única diferença é que, após classificar os âncoras na r-ésima rodada, os validadores apenas precisam calcular um novo mapeamento F' a partir da r+1-ésima rodada, com base na história causal dos âncoras ordenados na r-ésima rodada. Em seguida, os nós de validação começam a usar a função de seleção de âncoras atualizada F' para executar uma nova instância do Bullshark a partir da r+1-ésima rodada.
![万字详解Shoal框架：如何减少Aptos上的Bullshark Gota？]###https://img-cdn.gateio.im/webp-social/moments-1baf540693f376d93cb18ef3193593cc.webp(
) Eliminar latência
O tempo limite desempenha um papel crucial em todas as implementações BFT determinísticas baseadas em líderes. No entanto, a complexidade que introduzem aumenta o número de estados internos que precisam ser geridos e monitorizados, o que aumenta a complexidade do processo de depuração e requer mais técnicas de observabilidade.
O tempo de espera também aumentará significativamente a latência.