Estrutura Shoal: Como reduzir a latência do Bullshark na Aptos?
Visão Geral
Os Aptos labs resolveram dois importantes problemas abertos no DAG BFT, reduzindo significativamente a latência e eliminando pela primeira vez a necessidade de pausas em protocolos reais determinísticos. De forma geral, melhoraram a latência do Bullshark em 40% em situações sem falhas e em 80% em situações de falha.
Shoal é uma estrutura que melhora qualquer protocolo de consenso baseado em Narwhal (, como DAG-Rider, Tusk, Bullshark ), através de processamento em pipeline e um mecanismo de reputação de líder. O pipeline reduz a latência de ordenação do DAG ao introduzir um ponto âncora a cada rodada, enquanto a reputação do líder melhora ainda mais o problema de latência, garantindo que os pontos âncora estejam associados aos nós de validaçã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 timeouts em todos os cenários. Isso permite que o Shoal forneça uma propriedade que chamamos de resposta universal, que inclui a resposta otimista normalmente necessária.
A tecnologia é muito simples, envolvendo a execução sequencial de múltiplas instâncias do protocolo subjacente. Portanto, quando instanciamos com Bullshark, obtemos um grupo de "tubarões" que estão participando de uma corrida de revezamento.
Motivação
Ao buscar alta performance em redes de blockchain, as pessoas sempre estiveram atentas à redução da complexidade de comunicação. No entanto, essa abordagem não trouxe 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 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.
A Quorum Store, apresentada anteriormente, é uma implementação do Narwhal que separa a propagação de dados do consenso, utilizada para escalar o atual protocolo de consenso Jolteon. Jolteon é um protocolo baseado em líderes que combina o caminho rápido linear do Tendermint com a mudança de vista no estilo PBFT, podendo reduzir 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. Apesar de separar a propagação de dados do consenso, à medida que o throughput aumenta, o líder do Hotstuff/Jolteon ainda enfrenta limitações.
Assim, decidiu-se 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 e alta capacidade de transações traz um custo de latência de 50%.
Este artigo apresenta como a Shoal reduziu significativamente a latência do Bullshark.
Contexto DAG-BFT
Cada vértice no Narwhal DAG está associado a um número de rodada. Para entrar na rodada r, um validador deve primeiro obter n-f vértices que pertencem à rodada r-1. Cada validador pode transmitir um vértice por rodada, e cada vértice deve referenciar pelo menos n-f vértices da rodada anterior. Devido à assíncronia da rede, diferentes validadores podem observar diferentes visões locais do DAG em qualquer ponto no tempo.
Uma propriedade chave do DAG é que não é ambígua: se dois nós de validação tiverem o mesmo vértice v em suas visões locais do DAG, então eles têm a mesma história causal de v.
Ordem Total
É possível chegar a um consenso sobre a ordem total de todos os vértices no DAG sem custos adicionais de comunicação. Para isso, os validadores no DAG-Rider, Tusk e Bullshark interpretam a estrutura do DAG como um protocolo de consenso, onde os vértices representam propostas e as arestas representam votos.
Embora a lógica de intersecção da comunidade na estrutura DAG seja diferente, todos os protocolos de consenso baseados em Narwhal existentes têm a seguinte estrutura:
Ponto de ancoragem: a cada várias rodadas haverá um líder previamente determinado, o ponto mais alto do líder é chamado de ponto de ancoragem;
Ponto de ancoragem de ordenação: os validadores decidem de forma independente, mas com determinação, quais pontos de ancoragem ordenar e quais pular;
História causal ordenada: os validadores processam um a um a lista de âncoras ordenadas, ordenando todos os vértices anteriores desordenados na história causal de cada âncora.
A chave para garantir a segurança é assegurar que na etapa (2), todas as listas de ancoragem ordenadas criadas pelos nós de validação honestos compartilhem o mesmo prefixo. No Shoal, fazemos as seguintes observações sobre todos os protocolos mencionados acima:
Todos os validadores concordam com o primeiro ponto de ancoragem ordenado.
Bullshark Delay
O atraso do Bullshark depende do número de rodadas entre os pontos âncora ordenados no DAG. Embora a versão sincronizada do Bullshark seja mais prática e tenha um atraso melhor do que a versão assíncrona, ainda está longe do ideal.
Pergunta 1: Atraso médio de bloco. No Bullshark, cada rodada par tem um ponto de ancoragem, enquanto o vértice da rodada ímpar é interpretado como um voto. Na maioria dos casos, são necessárias duas rodadas de DAG para ordenar os pontos de ancoragem; no entanto, os vértices na história causal do ponto de ancoragem precisam de mais rodadas para aguardar a ordenação do ponto de ancoragem. Na maioria dos casos, os vértices na rodada ímpar precisam de três rodadas, enquanto os vértices que não são pontos de ancoragem na rodada par precisam de quatro rodadas.
Pergunta 2: Atraso nos casos de falha. A análise de atraso acima se aplica a situações sem falha; por outro lado, se o líder de uma rodada não conseguir transmitir rapidamente o ponto de âncora, não será possível classificar o ponto de âncora (, que será, portanto, pulado ). Assim, todos os vértices não classificados das rodadas anteriores devem esperar que o próximo ponto de âncora seja classificado. Isso pode reduzir significativamente o desempenho da rede de replicação geográfica, especialmente porque o Bullshark usa timeouts para esperar pelo líder.
Estrutura Shoal
Shoal aprimorou o Bullshark( ou qualquer outro protocolo BFT baseado em Narwhal) através de 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 ancorados no DAG para três rodadas. Shoal também introduziu um mecanismo de reputação de líder de custo zero no DAG, o que faz com que a escolha favoreça líderes rápidos.
Desafio
No contexto do protocolo DAG, o processamento em pipeline e a reputação dos líderes são considerados problemas difíceis, pelos seguintes motivos:
As tentativas anteriores de processamento em linha de montagem para modificar a lógica central do Bullshark parecem, por essência, impossíveis.
A reputação dos líderes é introduzida no DiemBFT e formalizada no Carousel, sendo selecionados dinamicamente os futuros líderes com base no desempenho passado dos validadores, a ideia dos âncoras 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 traz à tona 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 chegar a um consenso sobre a história ordenada para escolher as âncoras futuras.
Como evidência da dificuldade do problema, notamos que a implementação do Bullshark, incluindo a implementação atual em ambiente de produção, não suporta essas características.
![Explicação detalhada do quadro Shoal: como reduzir a latência do Bullshark na Aptos?])https://img-cdn.gateio.im/webp-social/moments-0b0928cb6240e994c1514c75e080a4b2.webp(
Acordo
Apesar dos desafios mencionados, a solução está escondida na simplicidade.
No Shoal, confiamos na capacidade de realizar cálculos locais sobre o DAG e implementamos a capacidade de salvar e reinterpretar as informações das rodadas anteriores. Com a percepção central de que todos os validadores concordam com o primeiro ponto de ancoragem ordenado, o Shoal combina sequencialmente várias instâncias de Bullshark para processá-las em pipeline, tornando ) o primeiro ponto de ancoragem ordenado um ponto de transição das instâncias, bem como a história causal do ponto de ancoragem ( utilizada para calcular a reputação dos líderes.
Tratamento em linha de produção
V que mapeia a rodada ao líder. Shoal executa instâncias do Bullshark uma a uma, de tal forma que para cada instância, o ancla é pré-determinado pelo mapeamento F. Cada instância solicita um âncora, o que desencadeia a mudança para a próxima instância.
No início, Shoal lançou a primeira instância do Bullshark na primeira rodada do DAG e a operou 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 definitiva em reinterpretar o DAG a partir da rodada r+1. Shoal simplesmente lançou uma nova instância do Bullshark na rodada r+1.
No melhor cenário, isso permite que o Shoal peça um âncora em cada rodada. O ponto de âncora da primeira rodada é classificado pela primeira instância. Em seguida, o Shoal inicia uma nova instância na segunda rodada, que tem um ponto de âncora que é classificado por essa instância, e então, outra nova instância pede um ponto de âncora na terceira rodada, e o processo continua.
![Explicação detalhada do Shoal Framework: como reduzir a latência do Bullshark na Aptos?])https://img-cdn.gateio.im/webp-social/moments-859e732e16c3eee0e2c93422474debc2.webp(
Reputação do Líder
Durante a ordenação de Bullshark, o atraso aumenta ao pular pontos âncora. Nesse caso, a técnica de processamento em pipeline não pode ajudar, pois não é possível iniciar uma nova instância antes que o ponto âncora da instância anterior seja solicitado. A Shoal garante que é menos provável que os líderes correspondentes sejam escolhidos para processar pontos âncora perdidos no futuro, atribuindo uma pontuação a cada nó de validação com base no histórico de atividade recente de cada nó de validação, usando 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 receberão pontuações baixas, pois podem estar em colapso, lentos ou agindo de forma maliciosa.
A sua ideia é recalcular de forma determinística o mapeamento predefinido F do ciclo ao líder 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 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 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+ésima rodada, com base na história causal das âncoras ordenadas na r-ésima rodada. Em seguida, os nós validadores 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+ésima rodada.
![Análise detalhada do framework Shoal: como reduzir a latência do Bullshark na Aptos?])https://img-cdn.gateio.im/webp-social/moments-9f789cb669f6fcc244ea7ff7648e48b4.webp(
Sem mais tempo limite
O tempo limite desempenha um papel crucial em todas as implementações BFT determinísticas baseadas em líderes. No entanto, a complexidade que elas introduzem aumenta o número de estados internos que precisam ser geridos e monitorados, 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, pois é muito importante configurá-los adequadamente, e geralmente requer ajustes dinâmicos, uma vez que depende muito do ambiente ) rede (. Antes de mudar para o próximo líder, o protocolo aplicará uma penalização completa de latência pelo tempo de espera ao líder com falha. Portanto, as configurações de tempo de espera não podem ser excessivamente conservadoras, mas se o tempo de espera 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 ficam sobrecarregados e o tempo de espera ocorre antes de conseguirem avançar.
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.
21 gostos
Recompensa
21
9
Partilhar
Comentar
0/400
RektCoaster
· 08-03 07:00
latência caiu tanto? bull啊
Ver originalResponder0
Degen4Breakfast
· 08-02 20:25
Deixa pra lá, é preciso tanto trabalho para ser âncora.
Ver originalResponder0
SatoshiLegend
· 08-02 17:14
Apesar de a otimização do DAG ser boa, só mantendo a essência se pode alcançar o caminho. Sob o código-fonte não há segredos.
Ver originalResponder0
NonFungibleDegen
· 08-01 16:37
em alta af em aptos rn... 80% mais rápido? provavelmente nada ser
Ver originalResponder0
Ser_This_Is_A_Casino
· 07-31 12:48
Reduzir a latência pode resultar em algo assim.
Ver originalResponder0
BearMarketBro
· 07-31 12:48
Parece bom, eh
Ver originalResponder0
ApeShotFirst
· 07-31 12:25
Bela jogada, a Aptos está fazendo algo novo novamente!
Ver originalResponder0
GasFeeCrybaby
· 07-31 12:25
Quando é que as taxas de gás podem descer?
Ver originalResponder0
ImpermanentLossFan
· 07-31 12:24
Finalmente alguém se lembrou de mim, Ações tipo Aptos.
A estrutura Shoal melhora significativamente o desempenho do Bullshark na blockchain Aptos, reduzindo a latência em até 80%.
Estrutura Shoal: Como reduzir a latência do Bullshark na Aptos?
Visão Geral
Os Aptos labs resolveram dois importantes problemas abertos no DAG BFT, reduzindo significativamente a latência e eliminando pela primeira vez a necessidade de pausas em protocolos reais determinísticos. De forma geral, melhoraram a latência do Bullshark em 40% em situações sem falhas e em 80% em situações de falha.
Shoal é uma estrutura que melhora qualquer protocolo de consenso baseado em Narwhal (, como DAG-Rider, Tusk, Bullshark ), através de processamento em pipeline e um mecanismo de reputação de líder. O pipeline reduz a latência de ordenação do DAG ao introduzir um ponto âncora a cada rodada, enquanto a reputação do líder melhora ainda mais o problema de latência, garantindo que os pontos âncora estejam associados aos nós de validaçã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 timeouts em todos os cenários. Isso permite que o Shoal forneça uma propriedade que chamamos de resposta universal, que inclui a resposta otimista normalmente necessária.
A tecnologia é muito simples, envolvendo a execução sequencial de múltiplas instâncias do protocolo subjacente. Portanto, quando instanciamos com Bullshark, obtemos um grupo de "tubarões" que estão participando de uma corrida de revezamento.
Motivação
Ao buscar alta performance em redes de blockchain, as pessoas sempre estiveram atentas à redução da complexidade de comunicação. No entanto, essa abordagem não trouxe 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 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.
A Quorum Store, apresentada anteriormente, é uma implementação do Narwhal que separa a propagação de dados do consenso, utilizada para escalar o atual protocolo de consenso Jolteon. Jolteon é um protocolo baseado em líderes que combina o caminho rápido linear do Tendermint com a mudança de vista no estilo PBFT, podendo reduzir 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. Apesar de separar a propagação de dados do consenso, à medida que o throughput aumenta, o líder do Hotstuff/Jolteon ainda enfrenta limitações.
Assim, decidiu-se 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 e alta capacidade de transações traz um custo de latência de 50%.
Este artigo apresenta como a Shoal reduziu significativamente a latência do Bullshark.
Contexto DAG-BFT
Cada vértice no Narwhal DAG está associado a um número de rodada. Para entrar na rodada r, um validador deve primeiro obter n-f vértices que pertencem à rodada r-1. Cada validador pode transmitir um vértice por rodada, e cada vértice deve referenciar pelo menos n-f vértices da rodada anterior. Devido à assíncronia da rede, diferentes validadores podem observar diferentes visões locais do DAG em qualquer ponto no tempo.
Uma propriedade chave do DAG é que não é ambígua: se dois nós de validação tiverem o mesmo vértice v em suas visões locais do DAG, então eles têm a mesma história causal de v.
Ordem Total
É possível chegar a um consenso sobre a ordem total de todos os vértices no DAG sem custos adicionais de comunicação. Para isso, os validadores no DAG-Rider, Tusk e Bullshark interpretam a estrutura do DAG como um protocolo de consenso, onde os vértices representam propostas e as arestas representam votos.
Embora a lógica de intersecção da comunidade na estrutura DAG seja diferente, todos os protocolos de consenso baseados em Narwhal existentes têm a seguinte estrutura:
Ponto de ancoragem: a cada várias rodadas haverá um líder previamente determinado, o ponto mais alto do líder é chamado de ponto de ancoragem;
Ponto de ancoragem de ordenação: os validadores decidem de forma independente, mas com determinação, quais pontos de ancoragem ordenar e quais pular;
História causal ordenada: os validadores processam um a um a lista de âncoras ordenadas, ordenando todos os vértices anteriores desordenados na história causal de cada âncora.
A chave para garantir a segurança é assegurar que na etapa (2), todas as listas de ancoragem ordenadas criadas pelos nós de validação honestos compartilhem o mesmo prefixo. No Shoal, fazemos as seguintes observações sobre todos os protocolos mencionados acima:
Todos os validadores concordam com o primeiro ponto de ancoragem ordenado.
Bullshark Delay
O atraso do Bullshark depende do número de rodadas entre os pontos âncora ordenados no DAG. Embora a versão sincronizada do Bullshark seja mais prática e tenha um atraso melhor do que a versão assíncrona, ainda está longe do ideal.
Pergunta 1: Atraso médio de bloco. No Bullshark, cada rodada par tem um ponto de ancoragem, enquanto o vértice da rodada ímpar é interpretado como um voto. Na maioria dos casos, são necessárias duas rodadas de DAG para ordenar os pontos de ancoragem; no entanto, os vértices na história causal do ponto de ancoragem precisam de mais rodadas para aguardar a ordenação do ponto de ancoragem. Na maioria dos casos, os vértices na rodada ímpar precisam de três rodadas, enquanto os vértices que não são pontos de ancoragem na rodada par precisam de quatro rodadas.
Pergunta 2: Atraso nos casos de falha. A análise de atraso acima se aplica a situações sem falha; por outro lado, se o líder de uma rodada não conseguir transmitir rapidamente o ponto de âncora, não será possível classificar o ponto de âncora (, que será, portanto, pulado ). Assim, todos os vértices não classificados das rodadas anteriores devem esperar que o próximo ponto de âncora seja classificado. Isso pode reduzir significativamente o desempenho da rede de replicação geográfica, especialmente porque o Bullshark usa timeouts para esperar pelo líder.
Estrutura Shoal
Shoal aprimorou o Bullshark( ou qualquer outro protocolo BFT baseado em Narwhal) através de 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 ancorados no DAG para três rodadas. Shoal também introduziu um mecanismo de reputação de líder de custo zero no DAG, o que faz com que a escolha favoreça líderes rápidos.
Desafio
No contexto do protocolo DAG, o processamento em pipeline e a reputação dos líderes são considerados problemas difíceis, pelos seguintes motivos:
As tentativas anteriores de processamento em linha de montagem para modificar a lógica central do Bullshark parecem, por essência, impossíveis.
A reputação dos líderes é introduzida no DiemBFT e formalizada no Carousel, sendo selecionados dinamicamente os futuros líderes com base no desempenho passado dos validadores, a ideia dos âncoras 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 traz à tona 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 chegar a um consenso sobre a história ordenada para escolher as âncoras futuras.
Como evidência da dificuldade do problema, notamos que a implementação do Bullshark, incluindo a implementação atual em ambiente de produção, não suporta essas características.
![Explicação detalhada do quadro Shoal: como reduzir a latência do Bullshark na Aptos?])https://img-cdn.gateio.im/webp-social/moments-0b0928cb6240e994c1514c75e080a4b2.webp(
Acordo
Apesar dos desafios mencionados, a solução está escondida na simplicidade.
No Shoal, confiamos na capacidade de realizar cálculos locais sobre o DAG e implementamos a capacidade de salvar e reinterpretar as informações das rodadas anteriores. Com a percepção central de que todos os validadores concordam com o primeiro ponto de ancoragem ordenado, o Shoal combina sequencialmente várias instâncias de Bullshark para processá-las em pipeline, tornando ) o primeiro ponto de ancoragem ordenado um ponto de transição das instâncias, bem como a história causal do ponto de ancoragem ( utilizada para calcular a reputação dos líderes.
Tratamento em linha de produção
V que mapeia a rodada ao líder. Shoal executa instâncias do Bullshark uma a uma, de tal forma que para cada instância, o ancla é pré-determinado pelo mapeamento F. Cada instância solicita um âncora, o que desencadeia a mudança para a próxima instância.
No início, Shoal lançou a primeira instância do Bullshark na primeira rodada do DAG e a operou 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 definitiva em reinterpretar o DAG a partir da rodada r+1. Shoal simplesmente lançou uma nova instância do Bullshark na rodada r+1.
No melhor cenário, isso permite que o Shoal peça um âncora em cada rodada. O ponto de âncora da primeira rodada é classificado pela primeira instância. Em seguida, o Shoal inicia uma nova instância na segunda rodada, que tem um ponto de âncora que é classificado por essa instância, e então, outra nova instância pede um ponto de âncora na terceira rodada, e o processo continua.
![Explicação detalhada do Shoal Framework: como reduzir a latência do Bullshark na Aptos?])https://img-cdn.gateio.im/webp-social/moments-859e732e16c3eee0e2c93422474debc2.webp(
Reputação do Líder
Durante a ordenação de Bullshark, o atraso aumenta ao pular pontos âncora. Nesse caso, a técnica de processamento em pipeline não pode ajudar, pois não é possível iniciar uma nova instância antes que o ponto âncora da instância anterior seja solicitado. A Shoal garante que é menos provável que os líderes correspondentes sejam escolhidos para processar pontos âncora perdidos no futuro, atribuindo uma pontuação a cada nó de validação com base no histórico de atividade recente de cada nó de validação, usando 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 receberão pontuações baixas, pois podem estar em colapso, lentos ou agindo de forma maliciosa.
A sua ideia é recalcular de forma determinística o mapeamento predefinido F do ciclo ao líder 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 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 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+ésima rodada, com base na história causal das âncoras ordenadas na r-ésima rodada. Em seguida, os nós validadores 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+ésima rodada.
![Análise detalhada do framework Shoal: como reduzir a latência do Bullshark na Aptos?])https://img-cdn.gateio.im/webp-social/moments-9f789cb669f6fcc244ea7ff7648e48b4.webp(
Sem mais tempo limite
O tempo limite desempenha um papel crucial em todas as implementações BFT determinísticas baseadas em líderes. No entanto, a complexidade que elas introduzem aumenta o número de estados internos que precisam ser geridos e monitorados, 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, pois é muito importante configurá-los adequadamente, e geralmente requer ajustes dinâmicos, uma vez que depende muito do ambiente ) rede (. Antes de mudar para o próximo líder, o protocolo aplicará uma penalização completa de latência pelo tempo de espera ao líder com falha. Portanto, as configurações de tempo de espera não podem ser excessivamente conservadoras, mas se o tempo de espera 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 ficam sobrecarregados e o tempo de espera ocorre antes de conseguirem avançar.