A estrutura Shoal Gota significativamente a latência do Bullshark na Aptos, enquanto a linha de produção e o mecanismo de reputação melhoram de forma notável o desempenho.
Estrutura Shoal: Melhorando o atraso do Bullshark na Aptos
Aptos Labs recentemente resolveu dois problemas abertos importantes no DAG BFT, reduzindo significativamente a latência e eliminando pela primeira vez a necessidade de pausas em um protocolo prático determinístico. No geral, a latência do Bullshark melhorou em 40% em situações sem falhas e em 80% em situações de falhas.
Shoal é uma estrutura que aprimora qualquer protocolo de consenso baseado em Narwhal (, como DAG-Rider, Tusk, Bullshark ), através de pipeline e reputação de líderes. O pipeline reduz a latência de ordenação do DAG introduzindo um ponto âncora a cada rodada, enquanto a reputação do líder melhora ainda mais a latência ao garantir 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 o Shoal utilize a construção assíncrona do DAG para eliminar o tempo limite em todos os cenários. Isso permite que o Shoal forneça a propriedade que chamamos de resposta universal, que contém a resposta otimista normalmente necessária.
Tecnicamente, o Shoal executa várias instâncias do protocolo subjacente em ordem. Portanto, ao instanciar o Bullshark, obtemos um grupo de "tubarões" que estão participando de uma corrida de revezamento.
Motivação
Ao buscar 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 100k+ TPS.
A recente ruptura decorre da compreensão de que a propagação de dados é o principal gargalo baseado em protocolos de liderança, podendo beneficiar-se da paralelização. O sistema Narwhal separa a propagação de dados da lógica de consenso e propõe uma arquitetura onde todos os validadores propagam dados simultaneamente, com o componente de consenso apenas ordenando uma pequena quantidade de metadados. O artigo do Narwhal reportou uma taxa de transferência de 160.000 TPS.
Anteriormente, apresentamos o Quorum Store, que é a implementação do Narwhal, separando a propagação de dados do consenso, assim como como usá-lo para escalar o atual protocolo de consenso Jolteon. Jolteon é um protocolo baseado em líder 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, protocolos de consenso baseados em líder claramente não conseguem aproveitar totalmente 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, decidimos implementar o Bullshark sobre o Narwhal DAG, um protocolo de consenso com zero custo de comunicação. Infelizmente, em comparação com o Jolteon, a estrutura DAG que suporta o Bullshark com alta capacidade de processamento traz um custo de latência de 50%.
Este artigo apresenta como o Shoal pode reduzir significativamente a latência do Bullshark.
Contexto do DAG-BFT
Cada vértice no Narwhal DAG está relacionado a uma rodada. Para entrar na rodada r, os validadores devem 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 momento.
Uma propriedade chave do DAG é que não é ambígua: 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.
Prefácio
É possível alcançar um consenso sobre a ordem total de todos os vértices no DAG sem custos adicionais de comunicação. Para isso, os validadores em DAG-Rider, Tusk e Bullshark interpretam a estrutura do DAG como um protocolo de consenso, onde os vértices representam propostas e as arestas representam votos.
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 programado: a cada várias rodadas (, como em duas rodadas ) no Bullshark, haverá um líder previamente determinado, o ponto máximo do líder é chamado de ponto de âncora;
Ponto 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 lista de âncoras ordenadas, classificando todos os vértices anteriores não ordenados em sua história causal de acordo com regras determinísticas.
A chave para garantir a segurança é assegurar que, no passo (2), todas as listas de âncoras ordenadas criadas pelos nós de verificação honestos 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 ancoragem ordenado.
Bullshark atraso
A latência do Bullshark depende do número de rodadas entre os pontos âncora ordenados no DAG. Embora a versão sincronizada mais prática do Bullshark tenha uma latência melhor do que a versão assíncrona, ainda está longe de ser a ideal.
Pergunta 1: Atraso médio 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 do âncora precisam de mais rodadas para que o âncora seja ordenado. 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.
Pergunta 2: Atraso em 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 os pontos âncoras rapidamente o suficiente, a ordenação dos pontos âncoras não poderá ser realizada ( e, portanto, será pulada ). Assim, todos os vértices não ordenados nas rodadas anteriores devem aguardar a próxima ordenação do ponto âncora. Isso reduzirá significativamente o desempenho da rede de replicação geográfica, especialmente porque o Bullshark utiliza tempo limite para aguardar o líder.
Estrutura Shoal
Shoal resolveu esses dois problemas de latência, aprimorando o Bullshark( ou qualquer outro protocolo BFT baseado em Narwhal) através de pipeline, permitindo que haja um ponto de ancoragem a 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, que favorece a escolha de líderes rápidos.
Desafio
No contexto do protocolo DAG, o pipeline e a reputação do líder são considerados problemas difíceis, pelas seguintes razões:
As linhas de montagem anteriores 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 futuros líderes, a ideia do âncora no Bullshark (. Embora existam divergências na identidade do líder, isso não viola a segurança desses protocolos, mas no Bullshark, pode levar a uma ordenação completamente diferente, o que levanta o cerne da questão, ou seja, a escolha dinâmica e determinística do âncora do ciclo é necessária para resolver o consenso, e os validadores precisam chegar a um consenso sobre a história ordenada para escolher os futuros âncoras.
Como evidência da dificuldade do problema, notamos que a implementação do Bullshark, incluindo a implementação atual no ambiente de produção, não suporta essas características.
![Explicação detalhada do Shoal Framework: 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 verdade é que a solução está escondida na simplicidade.
No Shoal, dependemos da capacidade de executar cálculos locais na DAG e implementamos a capacidade de armazenar e reinterpretar informações das rodadas anteriores. Com a percepção central de que todos os validadores concordam com o primeiro ponto âncora ordenado, o Shoal combina sequencialmente várias instâncias de Bullshark para processá-las em pipeline, tornando ) o primeiro ponto âncora ordenado um ponto de mudança para as instâncias, e ( a história causal do ponto âncora utilizada para calcular a reputação do líder.
Linha de Montagem
V que mapeia as rodadas aos líderes. O Shoal executa instâncias do Bullshark uma após a outra, de modo que para cada instância, o âncora é previamente determinado pelo mapeamento F. Cada instância classifica um âncora, o que desencadeia a mudança 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 este ponto âncora. Assim, todos os validadores puderam concordar de forma definitiva 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 dos casos, isso permite que o Shoal classifique um âncora em cada rodada. O primeiro âncora é classificado pela primeira instância. Em seguida, o Shoal inicia uma nova instância na segunda rodada, que possui um âncora próprio, classificado por essa instância, e então, outra nova instância classifica o âncora na terceira rodada, e o processo continua.
![Explicação detalhada do framework Shoal: 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 o período de ordenação do Bullshark, a latência aumenta ao pular pontos de ancoragem. Nesse caso, a técnica de pipeline não pode ajudar, pois não é possível iniciar novas instâncias antes que o ponto de ancoragem da instância anterior seja ordenado. O Shoal garante que é menos provável que líderes correspondentes sejam escolhidos para lidar com pontos de ancoragem perdidos, atribuindo uma pontuação a cada nó de validação com base no histórico de atividades recentes de cada nó de validação usando 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 serão atribuídos com pontuações baixas, pois podem estar falhando, lentos ou agindo de forma maliciosa.
A sua ideia é recalcular de forma determinística o mapeamento predefinido F do turno ao líder sempre que a pontuação for atualizada, inclinando-se em direção aos líderes com pontuações mais altas. Para que os validadores concordem com 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.
Na Shoal, a linha de produção e a reputação de liderança podem se combinar naturalmente, pois ambas utilizam a mesma tecnologia central, que é a reinterpretação do DAG após o consenso no primeiro ponto de ancoragem ordenado.
Na verdade, a única diferença é que, após classificar os pontos âncora 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 pontos âncora ordenados da r-ésima rodada. Em seguida, os nós validadores começam a usar a função de seleção de pontos âncora atualizada F' para executar uma nova instância do Bullshark a partir da r+1-ésima rodada.
![Explicação detalhada do quadro Shoal: como reduzir a latência do Bullshark na Aptos?])https://img-cdn.gateio.im/webp-social/moments-9f789cb669f6fcc244ea7ff7648e48b4.webp(
Não há mais tempo de espera
O timeout desempenha um papel crucial em todas as implementações BFT determinísticas baseadas em líder. No entanto, a complexidade que 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 Timeout também pode aumentar significativamente a latência, pois é muito importante configurá-lo adequadamente e geralmente precisa de ajustes dinâmicos, uma vez que depende muito do ambiente ) rede (. Antes de passar para o próximo líder, o protocolo paga a penalidade total de latência de timeout para o líder com falha. Portanto, a configuração do timeout não pode ser excessivamente conservadora, mas se o tempo de timeout for muito curto, o protocolo pode pular líderes bons. Por exemplo, observamos que, em situações de alta carga, os líderes no Jolteon/Hotstuff ficam sobrecarregados e o timeout já expirou antes que eles pudessem avançar.
This page may contain third-party content, which is provided for information purposes only (not representations/warranties) and should not be considered as an endorsement of its views by Gate, nor as financial or professional advice. See Disclaimer for details.
16 gostos
Recompensa
16
4
Partilhar
Comentar
0/400
DeFiChef
· 9h atrás
Esse aumento de desempenho de 40% é maravilhoso!
Ver originalResponder0
TokenEconomist
· 07-02 09:36
na verdade, a arquitetura do shoal é uma obra-prima da teoria dos jogos. pense nisso como um equilíbrio de nash onde os validadores otimizam para reputação = f(velocidade, confiabilidade)...
Ver originalResponder0
WhaleSurfer
· 07-02 09:33
bullbullbull ultrapassou o limite!
Ver originalResponder0
TokenSleuth
· 07-02 09:24
Aptos está otimizado, bull, a latência caiu tanto.
A estrutura Shoal Gota significativamente a latência do Bullshark na Aptos, enquanto a linha de produção e o mecanismo de reputação melhoram de forma notável o desempenho.
Estrutura Shoal: Melhorando o atraso do Bullshark na Aptos
Aptos Labs recentemente resolveu dois problemas abertos importantes no DAG BFT, reduzindo significativamente a latência e eliminando pela primeira vez a necessidade de pausas em um protocolo prático determinístico. No geral, a latência do Bullshark melhorou em 40% em situações sem falhas e em 80% em situações de falhas.
Shoal é uma estrutura que aprimora qualquer protocolo de consenso baseado em Narwhal (, como DAG-Rider, Tusk, Bullshark ), através de pipeline e reputação de líderes. O pipeline reduz a latência de ordenação do DAG introduzindo um ponto âncora a cada rodada, enquanto a reputação do líder melhora ainda mais a latência ao garantir 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 o Shoal utilize a construção assíncrona do DAG para eliminar o tempo limite em todos os cenários. Isso permite que o Shoal forneça a propriedade que chamamos de resposta universal, que contém a resposta otimista normalmente necessária.
Tecnicamente, o Shoal executa várias instâncias do protocolo subjacente em ordem. Portanto, ao instanciar o Bullshark, obtemos um grupo de "tubarões" que estão participando de uma corrida de revezamento.
Motivação
Ao buscar 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 100k+ TPS.
A recente ruptura decorre da compreensão de que a propagação de dados é o principal gargalo baseado em protocolos de liderança, podendo beneficiar-se da paralelização. O sistema Narwhal separa a propagação de dados da lógica de consenso e propõe uma arquitetura onde todos os validadores propagam dados simultaneamente, com o componente de consenso apenas ordenando uma pequena quantidade de metadados. O artigo do Narwhal reportou uma taxa de transferência de 160.000 TPS.
Anteriormente, apresentamos o Quorum Store, que é a implementação do Narwhal, separando a propagação de dados do consenso, assim como como usá-lo para escalar o atual protocolo de consenso Jolteon. Jolteon é um protocolo baseado em líder 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, protocolos de consenso baseados em líder claramente não conseguem aproveitar totalmente 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, decidimos implementar o Bullshark sobre o Narwhal DAG, um protocolo de consenso com zero custo de comunicação. Infelizmente, em comparação com o Jolteon, a estrutura DAG que suporta o Bullshark com alta capacidade de processamento traz um custo de latência de 50%.
Este artigo apresenta como o Shoal pode reduzir significativamente a latência do Bullshark.
Contexto do DAG-BFT
Cada vértice no Narwhal DAG está relacionado a uma rodada. Para entrar na rodada r, os validadores devem 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 momento.
Uma propriedade chave do DAG é que não é ambígua: 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.
Prefácio
É possível alcançar um consenso sobre a ordem total de todos os vértices no DAG sem custos adicionais de comunicação. Para isso, os validadores em DAG-Rider, Tusk e Bullshark interpretam a estrutura do DAG como um protocolo de consenso, onde os vértices representam propostas e as arestas representam votos.
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 programado: a cada várias rodadas (, como em duas rodadas ) no Bullshark, haverá um líder previamente determinado, o ponto máximo do líder é chamado de ponto de âncora;
Ponto 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 lista de âncoras ordenadas, classificando todos os vértices anteriores não ordenados em sua história causal de acordo com regras determinísticas.
A chave para garantir a segurança é assegurar que, no passo (2), todas as listas de âncoras ordenadas criadas pelos nós de verificação honestos 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 ancoragem ordenado.
Bullshark atraso
A latência do Bullshark depende do número de rodadas entre os pontos âncora ordenados no DAG. Embora a versão sincronizada mais prática do Bullshark tenha uma latência melhor do que a versão assíncrona, ainda está longe de ser a ideal.
Pergunta 1: Atraso médio 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 do âncora precisam de mais rodadas para que o âncora seja ordenado. 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.
Pergunta 2: Atraso em 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 os pontos âncoras rapidamente o suficiente, a ordenação dos pontos âncoras não poderá ser realizada ( e, portanto, será pulada ). Assim, todos os vértices não ordenados nas rodadas anteriores devem aguardar a próxima ordenação do ponto âncora. Isso reduzirá significativamente o desempenho da rede de replicação geográfica, especialmente porque o Bullshark utiliza tempo limite para aguardar o líder.
Estrutura Shoal
Shoal resolveu esses dois problemas de latência, aprimorando o Bullshark( ou qualquer outro protocolo BFT baseado em Narwhal) através de pipeline, permitindo que haja um ponto de ancoragem a 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, que favorece a escolha de líderes rápidos.
Desafio
No contexto do protocolo DAG, o pipeline e a reputação do líder são considerados problemas difíceis, pelas seguintes razões:
As linhas de montagem anteriores 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 futuros líderes, a ideia do âncora no Bullshark (. Embora existam divergências na identidade do líder, isso não viola a segurança desses protocolos, mas no Bullshark, pode levar a uma ordenação completamente diferente, o que levanta o cerne da questão, ou seja, a escolha dinâmica e determinística do âncora do ciclo é necessária para resolver o consenso, e os validadores precisam chegar a um consenso sobre a história ordenada para escolher os futuros âncoras.
Como evidência da dificuldade do problema, notamos que a implementação do Bullshark, incluindo a implementação atual no ambiente de produção, não suporta essas características.
![Explicação detalhada do Shoal Framework: 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 verdade é que a solução está escondida na simplicidade.
No Shoal, dependemos da capacidade de executar cálculos locais na DAG e implementamos a capacidade de armazenar e reinterpretar informações das rodadas anteriores. Com a percepção central de que todos os validadores concordam com o primeiro ponto âncora ordenado, o Shoal combina sequencialmente várias instâncias de Bullshark para processá-las em pipeline, tornando ) o primeiro ponto âncora ordenado um ponto de mudança para as instâncias, e ( a história causal do ponto âncora utilizada para calcular a reputação do líder.
Linha de Montagem
V que mapeia as rodadas aos líderes. O Shoal executa instâncias do Bullshark uma após a outra, de modo que para cada instância, o âncora é previamente determinado pelo mapeamento F. Cada instância classifica um âncora, o que desencadeia a mudança 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 este ponto âncora. Assim, todos os validadores puderam concordar de forma definitiva 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 dos casos, isso permite que o Shoal classifique um âncora em cada rodada. O primeiro âncora é classificado pela primeira instância. Em seguida, o Shoal inicia uma nova instância na segunda rodada, que possui um âncora próprio, classificado por essa instância, e então, outra nova instância classifica o âncora na terceira rodada, e o processo continua.
![Explicação detalhada do framework Shoal: 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 o período de ordenação do Bullshark, a latência aumenta ao pular pontos de ancoragem. Nesse caso, a técnica de pipeline não pode ajudar, pois não é possível iniciar novas instâncias antes que o ponto de ancoragem da instância anterior seja ordenado. O Shoal garante que é menos provável que líderes correspondentes sejam escolhidos para lidar com pontos de ancoragem perdidos, atribuindo uma pontuação a cada nó de validação com base no histórico de atividades recentes de cada nó de validação usando 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 serão atribuídos com pontuações baixas, pois podem estar falhando, lentos ou agindo de forma maliciosa.
A sua ideia é recalcular de forma determinística o mapeamento predefinido F do turno ao líder sempre que a pontuação for atualizada, inclinando-se em direção aos líderes com pontuações mais altas. Para que os validadores concordem com 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.
Na Shoal, a linha de produção e a reputação de liderança podem se combinar naturalmente, pois ambas utilizam a mesma tecnologia central, que é a reinterpretação do DAG após o consenso no primeiro ponto de ancoragem ordenado.
Na verdade, a única diferença é que, após classificar os pontos âncora 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 pontos âncora ordenados da r-ésima rodada. Em seguida, os nós validadores começam a usar a função de seleção de pontos âncora atualizada F' para executar uma nova instância do Bullshark a partir da r+1-ésima rodada.
![Explicação detalhada do quadro Shoal: como reduzir a latência do Bullshark na Aptos?])https://img-cdn.gateio.im/webp-social/moments-9f789cb669f6fcc244ea7ff7648e48b4.webp(
Não há mais tempo de espera
O timeout desempenha um papel crucial em todas as implementações BFT determinísticas baseadas em líder. No entanto, a complexidade que 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 Timeout também pode aumentar significativamente a latência, pois é muito importante configurá-lo adequadamente e geralmente precisa de ajustes dinâmicos, uma vez que depende muito do ambiente ) rede (. Antes de passar para o próximo líder, o protocolo paga a penalidade total de latência de timeout para o líder com falha. Portanto, a configuração do timeout não pode ser excessivamente conservadora, mas se o tempo de timeout for muito curto, o protocolo pode pular líderes bons. Por exemplo, observamos que, em situações de alta carga, os líderes no Jolteon/Hotstuff ficam sobrecarregados e o timeout já expirou antes que eles pudessem avançar.
Infelizmente, baseado na liderança