O núcleo da blockchain é alcançar um consenso global rígido: ou seja, independentemente de onde os nós da rede estão distribuídos em que país ou fuso horário, todos os participantes devem, em última instância, chegar a um consenso sobre um conjunto de resultados objetivos.

Mas a realidade das redes distribuídas não é ideal: os nós ficam offline, os nós mentem e alguns até sabotam intencionalmente. Nesse caso, como o sistema “fala com uma só voz” e mantém a consistência?

Este é o problema que o protocolo de consenso visa resolver. É essencialmente um conjunto de regras para orientar um grupo de nós independentes e até parcialmente não confiáveis sobre como chegar a uma decisão unificada sobre a ordem e conteúdo de cada transação.

E uma vez estabelecido esse 'consenso rigoroso', o blockchain pode desbloquear muitos recursos-chave, como proteção de direitos de propriedade digital, modelos de moeda anti-inflacionária e estruturas escaláveis de colaboração social. Mas a premissa é que o próprio protocolo de consenso deve garantir dois aspectos fundamentais ao mesmo tempo:

• Dois blocos em conflito não podem ser confirmados;
• A rede deve continuar avançando e não pode ficar presa ou parar.

MonadBFT é a mais recente inovação tecnológica nesta direção.

Uma breve revisão da evolução dos protocolos de consenso

No campo do mecanismo de consenso, na verdade, tem sido estudado por décadas. O primeiro lote de protocolos, como PBFT (Tolerância a Falhas Bizantinas Práticas), já pode lidar com uma situação muito realista: mesmo se alguns nós na rede abandonarem a cadeia, se comportarem de maneira maliciosa ou falarem besteiras, contanto que não excedam um terço do número total, o sistema ainda pode chegar a um consenso.

O design desses protocolos iniciais é mais “tradicional”: um líder é selecionado em cada rodada para iniciar uma proposta, e outros validadores votam nesta proposta em várias rodadas para confirmar gradualmente a ordem da transação.

O processo de votação inteiro geralmente passa por várias etapas, como pré-preparação, preparação, compromisso e resposta. Em cada etapa, todos os validadores precisam se comunicar entre si. Em outras palavras, todos precisam informar a todos os outros, e o volume de mensagens cresce de forma explosiva em um padrão de 'malha'.

A complexidade desta estrutura de comunicação é n² - isto é, se houver 100 validadores na rede, cada rodada de consenso pode exigir a transmissão de quase 10.000 mensagens.

Em uma pequena rede, isso não é um problema, mas uma vez que o número de validadores aumenta, o fardo de comunicação do sistema rapidamente se tornará insuportável, afetando diretamente a eficiência.

Fonte de informação:https://medium.com/coinmonks/pbft-understanding-the-algorithm-b7a7869650ae

A estrutura de comunicação secundária 'todos falam com todos' na verdade é muito ineficiente. Por exemplo, em uma rede com 100 validadores, cada rodada de consenso pode precisar processar dezenas de milhares de mensagens.

Isso ainda pode ser gerenciado em um pequeno círculo, mas quando colocado em uma rede global e aberta, a carga de comunicação imediatamente se torna inaceitável. Portanto, protocolos BFT iniciais como PBFT e Tendermint geralmente são usados apenas em redes permissionadas ou sistemas com muito poucos validadores para funcionar precariamente.

Para permitir que o protocolo BFT se adapte a ambientes de cadeia pública e sem permissão, alguns designs de próxima geração estão se movendo em direção a métodos de comunicação mais leves: permitindo que cada validador se comunique apenas com o líder, em vez de com todos os membros.

Isso otimiza a complexidade da mensagem do original n² para n, reduzindo significativamente a carga do sistema.

O protocolo HotStuff foi proposto em 2018 para abordar esse problema de escalabilidade. Sua filosofia de design é muito clara: substituir o processo de votação complexo do PBFT por uma estrutura de comunicação mais concisa, liderada pelo líder.

Uma das principais características do HotStuff é a chamada comunicação linear. Em seu mecanismo, cada validador só precisa enviar seu voto para o líder atual, que então empacota esses votos para gerar um Certificado de Quórum (CQ).

Este QC é essencialmente uma assinatura coletiva, provando para toda a rede: 'A maioria dos nós concorda com esta proposta.'

Em contraste, o modo de comunicação do PBFT é 'transmitir para todos', onde todos falam no grupo, levando a uma cena caótica às vezes. O modo do HotStuff é mais como 'um reúne, um empacota de cada vez', o que pode manter a operação eficiente, independentemente de quantas pessoas estão na rede.

A figura compara a estrutura de comunicação fan-out do HotStuff com o modo totalmente interconectado do PBFT Fonte:

https://www.mdpi.com/1424-8220/24/16/5417

Além da comunicação linear, o HotStuff pode ser ainda mais aprimorado para uma versão em pipeline, usada para melhorar a eficiência.

No HotStuff original, o mesmo validador servirá como líder por várias rodadas seguidas, até que um bloco seja totalmente confirmado. Este processo é 'processando um bloco por rodada', com todos os esforços focados em avançar o atual.

No pipeline HotStuff, o mecanismo é ainda mais flexível: um novo líder é selecionado em cada rodada, e cada líder tem duas tarefas:

• Empacote a última rodada de votos em um Certificado de Quórum (QC) de um lado e transmita para toda a rede;
• De um lado, proponha um novo bloco, pronto para iniciar a próxima rodada.

Em outras palavras, não é mais "confirmar um antes de processar o próximo", mas como uma linha de produção, diferentes líderes se revezam para serem responsáveis por cada etapa. O anterior propõe um bloco, o próximo o confirma e continua a propor novos blocos, e o consenso na cadeia é passado como uma corrida de revezamento.

Esta é a origem da metáfora da “linha de montagem”: o bloco atual ainda está no processo de confirmação, enquanto o próximo já está em preparação, múltiplas etapas estão em paralelo, aumentando a eficiência da capacidade de processamento.

Em resumo, protocolos como HotStuff fizeram melhorias significativas em relação ao BFT tradicional em duas dimensões:

• Primeiro, a comunicação é mais leve, com cada validador precisando se comunicar apenas com o líder;
• Em segundo lugar, a eficiência de processamento é maior e vários processos de confirmação de blocos podem ser executados em paralelo.

Isso torna o HotStuff um modelo de design para muitos mecanismos de consenso de blockchain PoS modernos. Mas tudo tem seus prós e contras - enquanto a estrutura de pipeline é poderosa em desempenho, também introduz silenciosamente um risco estrutural não facilmente descobrível.

Em seguida, vamos aprofundar nessa questão central: Tail Forking.

Problema de Tail-Forking no final

Embora o HotStuff, especialmente sua versão em pipeline, resolva o problema de escalabilidade do protocolo de consenso, também introduz alguns novos desafios. O mais crucial e facilmente negligenciado é o chamado problema de "Tail Forking".

O que é um garfo de cauda? Pode ser simplesmente entendido como: um blockchain passa por uma reorganização acidental de blocos na 'cauda' da cadeia.

Específicamente, existe um bloco que é válido, foi propagado com sucesso para a maioria dos validadores e recebeu votos suficientes. Em teoria, deveria ser confirmado e escrito imediatamente na cadeia principal. No entanto, no final, ele é "ignorado", órfão e substituído por outro novo bloco na mesma altura.

Isto não é um Bug, nem um ataque, mas devido à estrutura de design do próprio protocolo, existe a possibilidade desse 'chain tailing'. Isso soa um pouco injusto? Então, como isso acontece?

Como mencionamos anteriormente, cada líder do pipeline HotStuff tem duas tarefas:

• A. Propor um novo bloco (como Bₙ₊₁)
• B. Coletar votos para o bloco do líder anterior para gerar QC (por exemplo, para finalmente confirmar Bₙ)

Essas duas tarefas são paralelas, revezando-se para relatar. Mas o problema surge aqui.

Por exemplo, suponha que Alice seja a líder e ela propôs o bloco Bₙ na altura n, que recebeu uma supermaioria de votos e está "quase confirmado".

Em seguida, deve ser a vez de Bob assumir o papel de líder, continuar avançando para o próximo bloco Bₙ₊₁ da cadeia e também incluir o QC (Qualified Commitment) de Bₙ em sua proposta para completar a confirmação final de Bₙ.

Mas se Bob estiver offline neste momento, ou se ele não enviar intencionalmente o QC de Bₙ, então há um problema.

Como ninguém empacotou o bloco de Alice com QC, o registro de votação de Bₙ não se espalhou. Este bloco, que deveria ter sido confirmado, foi assim 'processado a frio' e, por fim, ignorado por toda a rede.

Esta é a essência de um garfo de cauda: um bloco do líder anterior é pulado devido à negligência ou malícia do próximo líder.

Por que o garfo da cauda é tão severo?

O problema do garfo de cauda se concentra principalmente em dois aspectos: 1) o mecanismo de incentivo é interrompido, 2) a atividade do sistema é ameaçada.

Primeiro, as recompensas são engolidas:

Se um bloco for abandonado, o líder que o propôs não receberá nenhuma recompensa, seja recompensas em bloco ou taxas de transação. Por exemplo, se Alice propôs um bloco válido e recebeu apoio esmagador na votação, mas devido a um erro ou operação maliciosa de Bob, o bloco não pôde ser confirmado, Alice não receberá um centavo no final. Isso levará a uma estrutura de incentivo falha: nós maliciosos como Bob podem 'cortar' sua fonte de recompensa pulando os blocos de seus oponentes. Esse comportamento não requer ataques técnicos, apenas 'não cooperação' deliberada para enfraquecer os lucros dos concorrentes. Se isso acontecer repetidamente, com o tempo, a participação e a equidade de todo o sistema diminuirão e até mesmo poderão desencadear a colusão entre os nós.

Segundo, a superfície de ataque do MEV se expande:

Os garfos de cauda também representam um problema mais insidioso, porém sério: há mais espaço para que o MEV (Valor Máximo Extraível) seja manipulado de forma maliciosa. Aqui está um exemplo: Digamos que Alice tem uma operação valiosa de arbitragem em seu bloco. Se Bob quiser criar problemas, ele pode conspirar com o próximo líder, Carol, e deliberadamente não divulgar o bloco de Alice. Carol então reconstrói um novo bloco na mesma altura, "roubando" a operação original de arbitragem de Alice - fazendo com que o ganho de MEV seja dele. Essa prática de "rearranjo da cabeça da cadeia + conspiração e apropriação" ainda é um bloco de acordo com as regras superficialmente, mas na verdade é um saque bem planejado. Ainda pior, induz a "conspiração" entre os líderes, transformando a confirmação do bloco em um jogo de compartilhamento de benefícios, em vez de um serviço público.

Terceiro, minar a garantia de finalidade, afetando a experiência do usuário:

Comparado aos protocolos semelhantes ao de Nakamoto, uma grande vantagem do BFT é a finalidade determinística: uma vez que um bloco é confirmado, ele não pode ser revertido. No entanto, o tail fork disrupta essa garantia, especialmente em blocos que estão 'pré-confirmados, mas não formalmente confirmados'. Alguns dapps de alto rendimento frequentemente desejam ler dados imediatamente após a votação do bloco para reduzir a latência e, se o bloco for repentinamente descartado, pode causar um rollback do estado do usuário, como saldos de conta anormais, negociações de alta alavancagem que foram concluídas desaparecendo sem motivo, ou resets repentinos do estado do jogo.

Quarto, pode causar uma falha em cadeia:

Em geral, um garfo de cauda pode apenas atrasar a confirmação de um bloco por uma rodada, o que não tem um grande impacto. No entanto, em alguns casos extremos, se vários líderes seguidos optarem por pular o bloco anterior, o sistema pode ficar travado, e ninguém estará disposto a 'assumir' o bloco anterior. A cadeia inteira fica parada até que um líder disposto a assumir a responsabilidade finalmente apareça, e a rede continuará a avançar.

Embora tenham existido algumas soluções antes, como o mecanismo de evitar fork de cauda proposto pelo protocolo BeeGees, muitas vezes exigem sacrificar o desempenho, como reintroduzir complexidade de comunicação secundária, o que não vale a perda.

O que é MonadBFT?

MonadBFT é um protocolo de consenso de nova geração projetado especificamente para resolver o problema do garfo de cauda. Sua força está em: ao abordar vulnerabilidades estruturais, não sacrifica as vantagens de desempenho trazidas pelo pipeline HotStuff. Em outras palavras, MonadBFT não está recomeçando, mas sim continuando a otimização com base no framework principal do HotStuff. Ele mantém três características-chave:

1) Líder rotativo: Selecionar um novo líder para cada rodada para impulsionar a cadeia para frente;
2) Compromissos em cascata: Processos de confirmação de vários blocos podem se sobrepor;
3) Comunicação Linear (mensagens lineares): Cada validador só precisa se comunicar com o líder, economizando muita sobrecarga de rede.

Mas depender apenas desses três pontos não é seguro o suficiente. Para corrigir a vulnerabilidade estrutural do garfo traseiro, o MonadBFT adicionou dois mecanismos-chave:

1) Mecanismo de reproporção obrigatória (Re-Proposta)
2) Certificado de Não-Endosso (NEC)

Mecanismo de Re-Proposta

No protocolo BFT, o tempo é dividido em rodadas (chamadas de visualizações), com um líder em cada rodada responsável por propor um novo bloco. Se o líder falhar (por exemplo, não propor um bloco a tempo ou com uma proposta inválida), o sistema muda para a próxima rodada e seleciona um novo líder.

MonadBFT adicionou um mecanismo para garantir que quaisquer blocos honestamente propostos durante o processo de troca de visualização não 'derrubarão a cadeia' devido à rotação do líder.

Quando o líder atual falha, os validadores enviarão uma mensagem assinada para uma troca de rodada (mudança de visão), indicando que a rodada atual expirou.

Em particular, esta mensagem não apenas indica 'tempo esgotado', mas também deve incluir as informações do bloco do voto recente do validador, o que equivale a dizer, 'não recebi uma proposta válida, este é o último bloco que vejo atualmente.'

A nova rodada de líderes irá coletar essas mensagens de timeout da supermaioria (2f+1) validadores e fundi-las em um Certificado de Timeout (TC). Este TC representa a imagem cognitiva unificada do 'bloco cabeça de corrente' de toda a rede quando a rodada anterior falha. O novo líder irá selecionar o bloco com a maior altura (ou o último número de visualização), conhecido como high_tip, a partir dele.

MonadBFT requer: A proposta de um novo líder deve incluir um TC válido e deve reprovar o bloco pendente mais alto no TC para dar a este bloco outra chance de ser confirmado.

Por quê? Como mencionado anteriormente: não queremos que um bloco que está perto de ser confirmado desapareça.

Por exemplo, suponha que Alice seja a líder da visão 5, tenha proposto um bloco válido e recebido a maioria dos votos. Em seguida, quando o líder da visão 6, Bob, estiver offline e falhar em avançar o processo da cadeia, no momento em que Carol assume como líder da visão 7, de acordo com as regras do MonadBFT, ela deve incluir TC e repropor o bloco de Alice. Dessa forma, o trabalho honesto de Alice não será em vão.

Se Carol não tiver o bloco de Alice, ela pode solicitá-lo a outros nós. Nós podem:

• Fornecer o bloco, ou
• Retorne uma mensagem assinada de 'Sem-Endosso (NE)', indicando que o remetente não possui este bloco (seu mecanismo é explicado posteriormente). (Até f nós bizantinos podem optar por ignorar a solicitação e não responder.)

Uma vez que Carol reproponha o bloco de Alice, ela terá uma oportunidade de proposta adicional para garantir que não seja 'implicada' devido à falha do líder anterior.

O papel desse mecanismo de reproposição é claro: garantir que o avanço da cadeia seja justo e que nenhum trabalho válido seja descartado silenciosamente devido a má sorte ou sabotagem de alguém.

Certificado Não Endossável (CNE)

Continuando com o exemplo anterior: Após o tempo de espera de Bob expirar, Carol solicita que outros validadores forneçam o bloco high_tip (ou seja, o bloco de Alice). Neste ponto, pelo menos 2f+1 validadores responderão:

• Fornecer os blocos de Alice
• Envie uma mensagem NE assinada indicando que você não recebeu o bloco de Alice.

Desde que Carol receba o bloco de Alice, ela deve repropostá-lo de acordo com as regras. Carol só pode pular o bloco e propor um novo quando pelo menos f+1 validadores tiverem assinado a mensagem NE.

Por que f+1? Em um sistema BFT composto por 3f+1 validadores, no máximo apenas f podem ser maliciosos. Se o bloco da Alice de fato recebeu uma supermaioria de votos, então pelo menos 2f+1 nós honestos o receberam.

Portanto, se Carol afirmar: “Não consigo obter o bloco de Alice”, ela deve produzir assinaturas de f+1 validadores para provar que nenhum deles o recebeu. Isso constitui um Certificado de Não-Endosso (NEC).

NEC é a credencial de "isenção de responsabilidade" de um líder: é uma evidência verificável de que o bloqueio anterior não está pronto para ser confirmado, não foi ignorado maliciosamente, mas "abandonado" com motivos.

Re-proposta + Certificado não endossado = Resolver o garfo de cauda

MonadBFT introduz um conjunto de regras de processamento de cabeçalho de cadeia rigorosas e claras por meio da introdução do mecanismo de reproposta e do Certificado de Não-Endosso (NEC).

Ou finalmente comprometa-se com o bloco ‘quase confirmado’;

Forneça evidências suficientes para provar que o bloco ainda não está pronto para ser confirmado,

Caso contrário, não é permitido pular ou substituir o bloco anterior.

Este mecanismo garante que qualquer bloco que tenha recebido a maioria legal de votos não será abandonado devido a erros do líder ou contornos intencionais.

Os riscos estruturais do garfo da cauda são resolvidos sistematicamente, e o protocolo pode claramente conter comportamentos inadequados de salto.

Se um líder tentar pular o bloco anterior sem fornecer evidências NEC, o protocolo reconhecerá imediatamente e rejeitará o comportamento. Comportamento de salto sem evidência criptográfica será considerado ilegal e não receberá suporte de consenso de rede.

Sob a perspectiva de incentivo econômico, este design oferece proteção clara para os validadores:

• Desde que o bloco seja honestamente proposto e receba apoio na votação, a sua recompensa não será retirada devido a falhas subsequentes.
• Mesmo em situações extremas, como quando um nó deliberadamente pula sua própria rodada de proposta e tenta ajudar outros a aproveitar o MEV do bloco anterior, o protocolo forçará o líder subsequente a priorizar a reproposição do bloco original, impedindo que o atacante obtenha benefícios econômicos ao pular o processo.

Mais importante, o MonadBFT não sacrificou o desempenho do protocolo para aumentar a segurança.

Alguns designs que abordam forks de cauda (como o protocolo BeeGees) no passado têm certas capacidades de proteção, mas muitas vezes dependem de alta complexidade de comunicação (n²) ou permitem processos de comunicação pesados em cada rodada, o que aumenta significativamente a carga do sistema na prática.

A estratégia de design do MonadBFT é mais sofisticada:

Comunicação adicional (como mensagens de tempo esgotado, reproposições de bloco) é apenas iniciada quando a visualização falha ou existem anomalias. No caminho regular onde a maioria dos líderes honestos continuamente produz blocos, o protocolo ainda mantém um estado operacional leve e eficiente.

O equilíbrio dinâmico entre desempenho e segurança é precisamente uma das principais vantagens do MonadBFT sobre seus protocolos predecessores.

Resumo

Este artigo analisa o mecanismo básico do consenso tradicional PBFT, organiza o caminho de desenvolvimento do protocolo HotStuff e foca em como o MonadBFT resolve o problema inerente do garfo de cauda da tubulação HotStuff na estrutura do protocolo.

Os garfos traseiros podem distorcer os incentivos econômicos dos proponentes de blocos e representar uma potencial ameaça à atividade da rede. O MonadBFT garante que qualquer bloco proposto por líderes honestos e aprovado por uma maioria estatutária não será abandonado ou ignorado, introduzindo um mecanismo de reproposição e Certificado Não Endossado (NEC).

No próximo artigo, continuaremos a explorar as outras duas características principais do MonadBFT:

1）Finalidade Especulativa
2）Responsividade otimista

Análise mais aprofundada desses mecanismos e sua significância prática para validadores e desenvolvedores.

Declaração:

1. Este artigo é reproduzido de [michael_lwy], os direitos autorais pertencem ao autor original [michael_lwy]，se tiver alguma objeção à reimpressão, entre em contatoEquipe de Aprendizado da Gate)，a equipe lidará com isso o mais rápido possível de acordo com o processo relevante.
2. Aviso Legal: As visões e opiniões expressas neste artigo são exclusivamente do autor e não constituem nenhum conselho de investimento.
3. As outras versões do idioma do artigo são traduzidas pela equipe Gate Learn, sem mencionarGate.ioNão copie, distribua ou cometa plágio de artigos traduzidos sem permissão.