Shoal Framework: Inovação para melhorar o desempenho da Blockchain Aptos
Aptos Labs recentemente apresentou o framework Shoal, que visa resolver dois problemas-chave no consenso DAG BFT, reduzindo significativamente a latência e eliminando pela primeira vez a dependência de timeouts em protocolos assíncronos determinísticos. De forma geral, o Shoal aumentou a latência do Bullshark em 40% em situações sem falhas e em 80% em situações com falhas.
Shoal melhora o protocolo de consenso baseado em Narwhal ( através de uma linha de montagem e um mecanismo de reputação do líder, como DAG-Rider, Tusk, Bullshark, etc. ). A tecnologia de linha de montagem reduz a latência de ordenação do DAG ao introduzir um ponto âncora a cada rodada, enquanto o mecanismo de reputação do líder melhora ainda mais a latência, assegurando que o ponto âncora esteja associado ao nó de validação mais rápido. Além disso, a reputação do líder permite que Shoal utilize a construção de DAG assíncrono para eliminar timeouts em todos os cenários, alcançando assim uma responsividade universal.
A ideia central do Shoal é executar várias instâncias do protocolo subjacente em ordem. Tomando o Bullshark como exemplo, pode-se imaginá-lo como um grupo de "tubarões" correndo em uma corrida de revezamento.
Motivação
A rede Blockchain tem buscado desempenho mais elevado, focando inicialmente na redução da complexidade da 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 100.000+ TPS.
As recentes quebras vêm do reconhecimento de que a propagação de dados é o principal gargalo baseado no protocolo de líderes, que pode beneficiar-se da paralelização. O sistema Narwhal separa a propagação de dados da lógica de consenso central, propondo uma arquitetura onde todos os validadores propagam dados simultaneamente, enquanto o componente de consenso apenas ordena uma pequena quantidade de metadados, alcançando 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 sendo utilizado para escalar o protocolo de consenso atual Jolteon. Jolteon combina o caminho rápido linear do Tendermint com a mudança de visualização no estilo PBFT, reduzindo a latência do Hotstuff em 33%. No entanto, os protocolos de consenso baseados em líderes não conseguem aproveitar plenamente o potencial de throughput do Narwhal.
Assim, a Aptos decidiu implementar o Bullshark sobre o DAG Narwhal, um protocolo de consenso com zero custo de comunicação. No entanto, a estrutura DAG de alto throughput do Bullshark traz um custo de latência de 50%. O objetivo da estrutura Shoal é reduzir significativamente a latência do Bullshark.
Background do DAG-BFT
Cada vértice no Narwhal DAG está relacionado a um número de rodada. Para entrar na rodada r, é necessário primeiro obter n-f vértices da rodada r-1. Cada validador pode difundir 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.
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 possuem a mesma história causal de v.
Ordenação total
É possível chegar a um consenso sobre a ordem total de todos os vértices no DAG sem custos de comunicação adicionais. Protocolos como 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 específica seja diferente, todos os protocolos de consenso baseados no Narwhal possuem a seguinte estrutura:
Ponto de ancoragem: a cada algumas rodadas há um líder previamente determinado, cujo ponto é chamado de ponto de ancoragem.
Ponto de ordenação: os validadores decidem de forma independente, mas determinística, quais pontos de ancoragem ordenar ou pular.
História causal ordenada: os validadores processam um por um a lista de âncoras ordenadas, ordenando os vértices não ordenados anteriormente na história causal de cada âncora.
A chave para garantir a segurança é assegurar que todos os nós de verificação honestos compartilhem a mesma prefixo da lista de âncoras ordenadas que criam. Shoal faz uma observação importante sobre todos esses protocolos: todos os validadores concordam com a primeira âncora ordenada.
Problemas de atraso do Bullshark
A latência do Bullshark depende do número de rodadas entre os pontos de ancoragem ordenados no DAG. Embora algumas versões sincronizadas tenham latência inferior às versões assíncronas, ainda estão longe do ideal.
Existem principalmente dois problemas:
Atraso médio de bloco: em situações comuns, os vértices ímpares precisam de três rodadas para ordenar, enquanto os vértices pares não âncoras precisam de quatro rodadas.
Atraso na situação de falha: Se um líder de rodada não conseguir transmitir o ponto âncora a tempo, esse ponto âncora será ignorado, e todos os vértices não ordenados das rodadas anteriores devem esperar pela ordenação do próximo ponto âncora. Isso reduz significativamente o desempenho da rede geograficamente distribuída, especialmente porque o Bullshark usa tempo de espera para o líder.
Shoal estrutura
Shoal melhora o Bullshark( ou qualquer protocolo BFT baseado em Narwhal) através de pipelines, permitindo que haja um ponto âncora a cada rodada, reduzindo a latência de todos os vértices não âncora para três rodadas. Shoal também introduz um mecanismo de reputação de líderes sem custo em DAG, tendendo a escolher líderes rápidos.
desafio
Implementar pipeline e reputação de líderes no protocolo DAG é considerado difícil:
Tentar modificar a lógica central do Bullshark anteriormente parece não ser viável.
A reputação dos líderes pode levar a diferentes classificações, e os validadores precisam alcançar um consenso sobre a história ordenada para escolher futuros pontos de âncora.
Como prova da dificuldade do problema, as implementações do Bullshark no ambiente de produção atualmente não suportam essas características.
Acordo
A solução do Shoal é relativamente simples. Ela aproveita a capacidade de realizar cálculos locais em DAG, implementando a funcionalidade de salvar e reinterpretar as informações das rodadas anteriores. Baseando-se na percepção de que todos os validadores concordam com o primeiro ponto âncora ordenado, o Shoal combina sequencialmente várias instâncias de Bullshark para processamento em pipeline, permitindo que:
O primeiro ponto de ancoragem ordenado é o ponto de mudança da instância
A história causal do ponto de âncora é usada para calcular a reputação do líder
linha de fluxo
V que mapeia a rodada para o líder. O Shoal executa instâncias do Bullshark em ordem, cada instância ordena um ponto âncora e aciona a transição para a próxima instância.
Shoal iniciou a primeira instância do Bullshark a partir da primeira rodada do DAG, até que o primeiro ponto de ancoragem ordenado ( fosse determinado na rodada r ). Todos os validadores concordaram com este ponto de ancoragem, portanto, podem concordar de forma determinística em reinterpretar o DAG a partir da rodada r+1. Shoal inicia uma nova instância do Bullshark na rodada r+1.
Idealmente, isso permite que o Shoal classifique um ponto de ancoragem por rodada. O primeiro ponto de ancoragem é classificado pela primeira instância, e então, na segunda rodada, uma nova instância classifica o ponto de ancoragem daquela rodada, e assim por diante.
Reputação do líder
Quando o Bullshark salta o ponto de ancoragem, o atraso aumenta. A tecnologia de pipeline não pode ajudar neste caso, pois é necessário esperar que a instância anterior classifique o ponto de ancoragem antes de iniciar uma nova instância. O Shoal atribui uma pontuação a cada nó de validação através de um mecanismo de reputação, com base no seu histórico de atividades recentes. Validadores que respondem rapidamente obtêm altas pontuações, caso contrário, recebem baixas pontuações.
A ideia é recalcular de forma determinística o mapeamento F do round ao líder sempre que a pontuação for atualizada, favorecendo líderes de alta pontuação. Para que os validadores cheguem a um consenso sobre o novo mapeamento, eles precisam alcançar um consenso sobre a pontuação, e assim, chegar a um consenso sobre a história utilizada para derivar a pontuação.
No Shoal, a reputação do pipeline e do líder pode se combinar naturalmente, pois ambas são baseadas na reinterpretação do DAG após alcançar consenso no primeiro ponto de âncora ordenado. A única diferença é que, após o ponto de âncora na rodada r, os validadores calculam o novo mapeamento F' a partir da rodada r+1 com base na história causal desse ponto de âncora. Em seguida, a nova instância do Bullshark é executada a partir da rodada r+1 usando o F' atualizado.
Eliminar o tempo limite
O tempo limite é crucial em todas as implementações BFT determinísticas baseadas em líderes. No entanto, eles aumentam a complexidade, exigindo mais gestão e observação do estado interno, tornando a depuração mais difícil.
O tempo limite também pode aumentar significativamente a latência, pois a configuração correta é importante e geralmente requer ajustes dinâmicos. Antes de mudar para o próximo líder, o protocolo deve 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 for muito curta, pode pular bons líderes.
Infelizmente, o protocolo baseado em líderes ( como Hotstuff e Jolteon ) essencialmente requer um tempo limite para garantir progresso em caso de falha do líder. Sem um tempo limite, até mesmo um líder em colapso pode parar o protocolo para sempre. Como não é possível distinguir entre uma falha e um líder lento durante períodos assíncronos, um tempo limite pode levar a nós de validação a substituir todos os líderes sem atividade de consenso.
No Bullshark, o tempo limite é utilizado para a construção do DAG, a fim de garantir que o líder honesto adicione pontos de ancoragem ao DAG rapidamente o suficiente durante a sincronização para a ordenação.
Observamos que a construção do DAG fornece um "relógio" que estima a velocidade da rede. Desde que n-f validadores honestos continuem a adicionar vértices ao DAG, a rodada avançará. Embora o Bullshark possa não conseguir classificar à velocidade da rede, o DAG ainda cresce à velocidade da rede. Por fim, quando um líder sem falhas transmitir âncoras rapidamente o suficiente, toda a história causal das âncoras será classificada.
Na avaliação, comparamos o Bullshark com e sem tempo limite:
Líder rápido: duas abordagens com o mesmo atraso, pois os pontos de ancoragem são ordenados e não utilizam tempo limite.
Líderes errados: Bullshark sem timeout com latência mais baixa, pois os nós de validação pularão imediatamente seu ponto de âncora.
Líderes lentos: o Bullshark sem tempo limite tem um desempenho melhor, pois os validadores aguardam o ponto âncora, enquanto o sem tempo limite pode pular o ponto âncora.
Em Shoal, evitar o tempo de espera está intimamente relacionado à reputação do líder. Esperar repetidamente por líderes lentos aumentará a latência, enquanto o mecanismo de reputação exclui validadores lentos de serem escolhidos como líderes. Assim, o sistema pode operar a uma velocidade de rede em todos os cenários reais.
É importante notar que o resultado da impossibilidade do FLP indica que não existe um protocolo de consenso determinístico que possa evitar completamente os timeouts. O Shoal não pode contornar esse resultado, pois teoricamente existem cronogramas de eventos adversariais que podem impedir que todos os pontos de ancoragem sejam ordenados. Em vez disso, após um número configurável de pontos de ancoragem pulados, o Shoal reverterá para o timeout. No entanto, na prática, essa situação é extremamente improvável de ocorrer.
Resposta Universal
O artigo sobre Hotstuff popularizou o conceito de resposta otimista, que intuitivamente significa que o protocolo pode, em boas condições, ( incluir líderes rápidos e uma rede sincronizada ) para operar na velocidade da rede.
Shoal oferece uma funcionalidade melhor, chamada de responsividade universal. Especificamente, em comparação com Hotstuff, mesmo que o líder falhe em um número configurável de rodadas contínuas ou a rede experimente ciclos assíncronos, Shoal continuará a operar à velocidade da rede.
A responsividade universal oferece garantias de progresso estritamente melhores durante períodos assíncronos e falhas do líder. Durante a sincronização com líderes lentos, essas características não podem ser comparadas diretamente, pois dependem da velocidade do líder. No entanto, considerando o mecanismo de reputação do líder, líderes lentos no Shoal devem ocorrer raramente.
Esta página pode conter conteúdo de terceiros, que é fornecido apenas para fins informativos (não para representações/garantias) e não deve ser considerada como um endosso de suas opiniões pela Gate nem como aconselhamento financeiro ou profissional. Consulte a Isenção de responsabilidade para obter detalhes.
18 Curtidas
Recompensa
18
7
Repostar
Compartilhar
Comentário
0/400
GasGrillMaster
· 22h atrás
Boa rapaziada latência cortada pela metade bull uau
Ver originalResponder0
MysteriousZhang
· 08-12 04:51
Quarenta por cento também se atreve a se gabar? kkk
Ver originalResponder0
SerumSquirter
· 08-12 04:50
Finalmente posso continuar a investir dinheiro aqui.
Ver originalResponder0
ContractCollector
· 08-12 04:48
Esta otimização de latência está muito forte!
Ver originalResponder0
LiquidityWitch
· 08-12 04:44
Isso é muito intenso, latência aumentou 40.
Ver originalResponder0
GateUser-26d7f434
· 08-12 04:41
Acelerar 40% pode correr com a Rede principal?
Ver originalResponder0
YieldHunter
· 08-12 04:41
tecnicamente falando... 40% não é mau, mas mostra-me as estatísticas de rendimento
Shoal framework: Aumento de 40% na latência da cadeia Aptos e eliminação da dependência de tempo limite
Shoal Framework: Inovação para melhorar o desempenho da Blockchain Aptos
Aptos Labs recentemente apresentou o framework Shoal, que visa resolver dois problemas-chave no consenso DAG BFT, reduzindo significativamente a latência e eliminando pela primeira vez a dependência de timeouts em protocolos assíncronos determinísticos. De forma geral, o Shoal aumentou a latência do Bullshark em 40% em situações sem falhas e em 80% em situações com falhas.
Shoal melhora o protocolo de consenso baseado em Narwhal ( através de uma linha de montagem e um mecanismo de reputação do líder, como DAG-Rider, Tusk, Bullshark, etc. ). A tecnologia de linha de montagem reduz a latência de ordenação do DAG ao introduzir um ponto âncora a cada rodada, enquanto o mecanismo de reputação do líder melhora ainda mais a latência, assegurando que o ponto âncora esteja associado ao nó de validação mais rápido. Além disso, a reputação do líder permite que Shoal utilize a construção de DAG assíncrono para eliminar timeouts em todos os cenários, alcançando assim uma responsividade universal.
A ideia central do Shoal é executar várias instâncias do protocolo subjacente em ordem. Tomando o Bullshark como exemplo, pode-se imaginá-lo como um grupo de "tubarões" correndo em uma corrida de revezamento.
Motivação
A rede Blockchain tem buscado desempenho mais elevado, focando inicialmente na redução da complexidade da 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 100.000+ TPS.
As recentes quebras vêm do reconhecimento de que a propagação de dados é o principal gargalo baseado no protocolo de líderes, que pode beneficiar-se da paralelização. O sistema Narwhal separa a propagação de dados da lógica de consenso central, propondo uma arquitetura onde todos os validadores propagam dados simultaneamente, enquanto o componente de consenso apenas ordena uma pequena quantidade de metadados, alcançando 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 sendo utilizado para escalar o protocolo de consenso atual Jolteon. Jolteon combina o caminho rápido linear do Tendermint com a mudança de visualização no estilo PBFT, reduzindo a latência do Hotstuff em 33%. No entanto, os protocolos de consenso baseados em líderes não conseguem aproveitar plenamente o potencial de throughput do Narwhal.
Assim, a Aptos decidiu implementar o Bullshark sobre o DAG Narwhal, um protocolo de consenso com zero custo de comunicação. No entanto, a estrutura DAG de alto throughput do Bullshark traz um custo de latência de 50%. O objetivo da estrutura Shoal é reduzir significativamente a latência do Bullshark.
Background do DAG-BFT
Cada vértice no Narwhal DAG está relacionado a um número de rodada. Para entrar na rodada r, é necessário primeiro obter n-f vértices da rodada r-1. Cada validador pode difundir 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.
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 possuem a mesma história causal de v.
Ordenação total
É possível chegar a um consenso sobre a ordem total de todos os vértices no DAG sem custos de comunicação adicionais. Protocolos como 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 específica seja diferente, todos os protocolos de consenso baseados no Narwhal possuem a seguinte estrutura:
Ponto de ancoragem: a cada algumas rodadas há um líder previamente determinado, cujo ponto é chamado de ponto de ancoragem.
Ponto de ordenação: os validadores decidem de forma independente, mas determinística, quais pontos de ancoragem ordenar ou pular.
História causal ordenada: os validadores processam um por um a lista de âncoras ordenadas, ordenando os vértices não ordenados anteriormente na história causal de cada âncora.
A chave para garantir a segurança é assegurar que todos os nós de verificação honestos compartilhem a mesma prefixo da lista de âncoras ordenadas que criam. Shoal faz uma observação importante sobre todos esses protocolos: todos os validadores concordam com a primeira âncora ordenada.
Problemas de atraso do Bullshark
A latência do Bullshark depende do número de rodadas entre os pontos de ancoragem ordenados no DAG. Embora algumas versões sincronizadas tenham latência inferior às versões assíncronas, ainda estão longe do ideal.
Existem principalmente dois problemas:
Atraso médio de bloco: em situações comuns, os vértices ímpares precisam de três rodadas para ordenar, enquanto os vértices pares não âncoras precisam de quatro rodadas.
Atraso na situação de falha: Se um líder de rodada não conseguir transmitir o ponto âncora a tempo, esse ponto âncora será ignorado, e todos os vértices não ordenados das rodadas anteriores devem esperar pela ordenação do próximo ponto âncora. Isso reduz significativamente o desempenho da rede geograficamente distribuída, especialmente porque o Bullshark usa tempo de espera para o líder.
Shoal estrutura
Shoal melhora o Bullshark( ou qualquer protocolo BFT baseado em Narwhal) através de pipelines, permitindo que haja um ponto âncora a cada rodada, reduzindo a latência de todos os vértices não âncora para três rodadas. Shoal também introduz um mecanismo de reputação de líderes sem custo em DAG, tendendo a escolher líderes rápidos.
desafio
Implementar pipeline e reputação de líderes no protocolo DAG é considerado difícil:
Tentar modificar a lógica central do Bullshark anteriormente parece não ser viável.
A reputação dos líderes pode levar a diferentes classificações, e os validadores precisam alcançar um consenso sobre a história ordenada para escolher futuros pontos de âncora.
Como prova da dificuldade do problema, as implementações do Bullshark no ambiente de produção atualmente não suportam essas características.
Acordo
A solução do Shoal é relativamente simples. Ela aproveita a capacidade de realizar cálculos locais em DAG, implementando a funcionalidade de salvar e reinterpretar as informações das rodadas anteriores. Baseando-se na percepção de que todos os validadores concordam com o primeiro ponto âncora ordenado, o Shoal combina sequencialmente várias instâncias de Bullshark para processamento em pipeline, permitindo que:
linha de fluxo
V que mapeia a rodada para o líder. O Shoal executa instâncias do Bullshark em ordem, cada instância ordena um ponto âncora e aciona a transição para a próxima instância.
Shoal iniciou a primeira instância do Bullshark a partir da primeira rodada do DAG, até que o primeiro ponto de ancoragem ordenado ( fosse determinado na rodada r ). Todos os validadores concordaram com este ponto de ancoragem, portanto, podem concordar de forma determinística em reinterpretar o DAG a partir da rodada r+1. Shoal inicia uma nova instância do Bullshark na rodada r+1.
Idealmente, isso permite que o Shoal classifique um ponto de ancoragem por rodada. O primeiro ponto de ancoragem é classificado pela primeira instância, e então, na segunda rodada, uma nova instância classifica o ponto de ancoragem daquela rodada, e assim por diante.
Reputação do líder
Quando o Bullshark salta o ponto de ancoragem, o atraso aumenta. A tecnologia de pipeline não pode ajudar neste caso, pois é necessário esperar que a instância anterior classifique o ponto de ancoragem antes de iniciar uma nova instância. O Shoal atribui uma pontuação a cada nó de validação através de um mecanismo de reputação, com base no seu histórico de atividades recentes. Validadores que respondem rapidamente obtêm altas pontuações, caso contrário, recebem baixas pontuações.
A ideia é recalcular de forma determinística o mapeamento F do round ao líder sempre que a pontuação for atualizada, favorecendo líderes de alta pontuação. Para que os validadores cheguem a um consenso sobre o novo mapeamento, eles precisam alcançar um consenso sobre a pontuação, e assim, chegar a um consenso sobre a história utilizada para derivar a pontuação.
No Shoal, a reputação do pipeline e do líder pode se combinar naturalmente, pois ambas são baseadas na reinterpretação do DAG após alcançar consenso no primeiro ponto de âncora ordenado. A única diferença é que, após o ponto de âncora na rodada r, os validadores calculam o novo mapeamento F' a partir da rodada r+1 com base na história causal desse ponto de âncora. Em seguida, a nova instância do Bullshark é executada a partir da rodada r+1 usando o F' atualizado.
Eliminar o tempo limite
O tempo limite é crucial em todas as implementações BFT determinísticas baseadas em líderes. No entanto, eles aumentam a complexidade, exigindo mais gestão e observação do estado interno, tornando a depuração mais difícil.
O tempo limite também pode aumentar significativamente a latência, pois a configuração correta é importante e geralmente requer ajustes dinâmicos. Antes de mudar para o próximo líder, o protocolo deve 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 for muito curta, pode pular bons líderes.
Infelizmente, o protocolo baseado em líderes ( como Hotstuff e Jolteon ) essencialmente requer um tempo limite para garantir progresso em caso de falha do líder. Sem um tempo limite, até mesmo um líder em colapso pode parar o protocolo para sempre. Como não é possível distinguir entre uma falha e um líder lento durante períodos assíncronos, um tempo limite pode levar a nós de validação a substituir todos os líderes sem atividade de consenso.
No Bullshark, o tempo limite é utilizado para a construção do DAG, a fim de garantir que o líder honesto adicione pontos de ancoragem ao DAG rapidamente o suficiente durante a sincronização para a ordenação.
Observamos que a construção do DAG fornece um "relógio" que estima a velocidade da rede. Desde que n-f validadores honestos continuem a adicionar vértices ao DAG, a rodada avançará. Embora o Bullshark possa não conseguir classificar à velocidade da rede, o DAG ainda cresce à velocidade da rede. Por fim, quando um líder sem falhas transmitir âncoras rapidamente o suficiente, toda a história causal das âncoras será classificada.
Na avaliação, comparamos o Bullshark com e sem tempo limite:
Líder rápido: duas abordagens com o mesmo atraso, pois os pontos de ancoragem são ordenados e não utilizam tempo limite.
Líderes errados: Bullshark sem timeout com latência mais baixa, pois os nós de validação pularão imediatamente seu ponto de âncora.
Líderes lentos: o Bullshark sem tempo limite tem um desempenho melhor, pois os validadores aguardam o ponto âncora, enquanto o sem tempo limite pode pular o ponto âncora.
Em Shoal, evitar o tempo de espera está intimamente relacionado à reputação do líder. Esperar repetidamente por líderes lentos aumentará a latência, enquanto o mecanismo de reputação exclui validadores lentos de serem escolhidos como líderes. Assim, o sistema pode operar a uma velocidade de rede em todos os cenários reais.
É importante notar que o resultado da impossibilidade do FLP indica que não existe um protocolo de consenso determinístico que possa evitar completamente os timeouts. O Shoal não pode contornar esse resultado, pois teoricamente existem cronogramas de eventos adversariais que podem impedir que todos os pontos de ancoragem sejam ordenados. Em vez disso, após um número configurável de pontos de ancoragem pulados, o Shoal reverterá para o timeout. No entanto, na prática, essa situação é extremamente improvável de ocorrer.
Resposta Universal
O artigo sobre Hotstuff popularizou o conceito de resposta otimista, que intuitivamente significa que o protocolo pode, em boas condições, ( incluir líderes rápidos e uma rede sincronizada ) para operar na velocidade da rede.
Shoal oferece uma funcionalidade melhor, chamada de responsividade universal. Especificamente, em comparação com Hotstuff, mesmo que o líder falhe em um número configurável de rodadas contínuas ou a rede experimente ciclos assíncronos, Shoal continuará a operar à velocidade da rede.
A responsividade universal oferece garantias de progresso estritamente melhores durante períodos assíncronos e falhas do líder. Durante a sincronização com líderes lentos, essas características não podem ser comparadas diretamente, pois dependem da velocidade do líder. No entanto, considerando o mecanismo de reputação do líder, líderes lentos no Shoal devem ocorrer raramente.
![万字详解Shoal框架：如何减