O cerne da blockchain é alcançar um consenso global rigoroso: ou seja, independentemente de onde os nós de rede estejam 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. Neste caso, como é que o sistema “fala a 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 o conteúdo de cada transação.

E uma vez estabelecido este 'consenso estrito', a blockchain pode desbloquear muitas características chave, como a 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 simultaneamente dois aspectos fundamentais.

• Dois blocos conflituosos não podem ambos ser confirmados;
• A rede deve continuar a avançar 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 há décadas. O primeiro lote de protocolos, como o PBFT (Tolerância a Falhas Bizantinas Práticas), já pode lidar com uma situação muito realista: mesmo que alguns nós na rede abandonem a cadeia, se comportem de maneira maliciosa ou falem besteiras, contanto que não excedam um terço do número total, o sistema ainda pode chegar a um consenso.

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

O processo de votação completo geralmente passa por várias etapas, como pré-preparação, preparação, compromisso e resposta. Em cada etapa, todos os validadores precisam comunicar entre si. Em outras palavras, todos têm de contar a todos os outros, e o volume de mensagens cresce de forma explosiva num 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.

Numa pequena rede, isso não é um problema, mas assim 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. Assim, os protocolos BFT iniciais como PBFT e Tendermint geralmente são usados apenas em redes com permissão ou sistemas com muito poucos validadores para mal funcionar.

Para permitir que o protocolo BFT se adapte a ambientes de cadeia pública 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 o fardo do sistema.

O protocolo HotStuff foi proposto em 2018 para resolver este 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 a 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 uma operação eficiente independentemente do número de pessoas na rede.

A figura compara a estrutura de comunicação de saída do HotStuff com o modo totalmente interligado do PBFT Fonte:

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

Para além da comunicação linear, o HotStuff pode ser ainda mais melhorado para uma versão em pipeline, utilizada 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 é ‘processar um bloco por rodada’, com todos os esforços concentrados 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:

• Agrupe a última rodada de votos em um Certificado de Quórum (QC) de um lado e transmita para toda a rede;
• Por um lado, propor um novo bloco, pronto para começar a próxima rodada.

Em outras palavras, já 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 é transmitido 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, vários passos são paralelos, 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 comunicar-se apenas com o líder;
• Em segundo lugar, a eficiência de processamento é maior e vários processos de confirmação de bloco podem ser executados em paralelo.

Isto torna o HotStuff num modelo de design para muitos mecanismos de consenso de blockchain PoS modernos. Mas tudo tem os 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.

A seguir, vamos aprofundar-nos nesta questão central: Tail Forking.

Problema de bifurcação de cauda no final

Embora o HotStuff, especialmente a 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 ignorado é o chamado problema de "Tail Forking".

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

Especificamente, existe um bloco que é válido, foi propagado com sucesso para a maioria dos validadores e recebeu votos suficientes. Na 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 deste ‘chain tailing’. Parece um pouco injusto? Então, como é que isto 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ₙ)

Estas duas tarefas são paralelas, alternando-se para transmitir. Mas o problema surge aqui.

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

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

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

Porque ninguém embalou o bloco de Alice com QC, o registo de votação de Bₙ não se espalhou. Este bloco, que deveria ter sido confirmado, foi assim 'processado a frio' e, no final, 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 da bifurcação da cauda foca 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á quaisquer recompensas, quer sejam recompensas de bloco ou taxas de transação. Por exemplo, se a Alice propôs um bloco válido e recebeu um apoio esmagador na votação, mas devido a um erro ou operação maliciosa do Bob, o bloco não pôde ser confirmado, a Alice não receberá um cêntimo no final. Isto levará a uma estrutura de incentivos defeituosa: nós maliciosos como o Bob podem 'cortar' a sua fonte de recompensa ao ignorar os blocos dos seus oponentes. Este comportamento não requer ataques técnicos, apenas 'não-cooperação' deliberada para enfraquecer os lucros dos concorrentes. Se isto acontecer repetidamente, ao longo do tempo, a participação e a justiça de todo o sistema irão diminuir, e até mesmo desencadear a conspiração entre os nós.

Em segundo lugar, a superfície de ataque do MEV expande-se:

Os garfos de cauda também representam um problema mais insidioso, mas sério: há mais espaço para o MEV (Valor Máximo Extraível) ser manipulado maliciosamente. Aqui está um exemplo: Vamos supor que a Alice tem uma negociação de arbitragem valiosa em seu bloco. Se o Bob quiser causar problemas, ele pode conspirar com o próximo líder, a Carol, e deliberadamente não espalhar o bloco da Alice. A Carol então reconstrói um novo bloco na mesma altura, “roubando” a negociação original de arbitragem da Alice - tornando o ganho de MEV seu. 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 projetado. Pior ainda, induz a “conspiração” entre os líderes, transformando a confirmação de blocos 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 utilizador:

Comparado com os protocolos do tipo Nakamoto, uma grande vantagem do BFT é a finalidade determinística: uma vez que um bloco é comprometido, não pode ser revertido. No entanto, o tail fork perturba essa garantia, especialmente em blocos que estão 'pré-comprometidos mas não formalmente confirmados.' Alguns dapps de alta capacidade frequentemente querem 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 contas anormais, negociações de alta alavancagem que acabaram de ser concluídas desaparecendo sem motivo, ou resetes 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 preso e ninguém estará disposto a "assumir" o bloco anterior. Toda a cadeia fica presa até que um líder disposto a assumir a responsabilidade finalmente apareça e a rede continuará a avançar.

Embora tenha havido algumas soluções anteriormente, como o mecanismo de evasão de bifurcações da cauda proposto pelo protocolo BeeGees, muitas vezes exigem sacrificar o desempenho, como reintroduzir a complexidade da 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 reside em: ao abordar vulnerabilidades estruturais, não sacrifica as vantagens de desempenho trazidas pelo pipeline HotStuff. Em outras palavras, o MonadBFT não está recomeçando, mas sim continuando a otimizar com base na estrutura 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 a frente;
2) Compromissos em pipeline: Os processos de confirmação de vários blocos podem sobrepor-se;
3) Comunicação Linear (mensagens lineares): Cada validador só precisa comunicar com o líder, poupando muita sobrecarga de rede.

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

1) Mecanismo de re-proposta obrigatório (Re-Proposta)
2) Certificado de Não Endosso (CNE)

Mecanismo de Re-Proposta

No protocolo BFT, o tempo é dividido em rondas (referidas como vistas), com um líder em cada ronda responsável por propor um novo bloco. Se o líder falhar (por exemplo, por não propor um bloco a tempo ou com uma proposta inválida), o sistema passa para a próxima ronda 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 irão 'abandonar 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 visualização), indicando que a rodada atual expirou.

Em particular, esta mensagem não só 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.'

Os novos líderes irão recolher estas mensagens de timeout da supermaioria (2f+1) dos validadores e fundi-las num Certificado de Timeout (TC). Este TC representa a visão cognitiva unificada do 'bloco principal da cadeia' de toda a rede quando a rodada anterior falha. O novo líder irá selecionar o bloco com a maior altura (ou o número de visualização mais recente), conhecido como high_tip, a partir dele.

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

Porquê? 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 fazer avançar o processo de 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 propor novamente o bloco de Alice. Dessa forma, o trabalho honesto de Alice não será em vão.

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

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

Uma vez que a Carol reapresenta o bloco da Alice, ela terá uma oportunidade de proposta extra para garantir que ela não seja 'implicada' devido ao fracasso do líder anterior.

O papel deste mecanismo de reproposta é 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 (NEC)

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 irão responder:

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

Desde que a Carol receba o bloco da Alice, ela deve propor novamente de acordo com as regras. A Carol só pode pular o bloco e propor um novo quando pelo menos f+1 validadores tenham assinado a mensagem NE.

Porque f+1? Num 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 nodos honestos o receberam.

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

NEC é uma credencial de “aviso” do líder: é uma evidência verificável de que o bloco anterior não está pronto para ser confirmado, não foi pulado maliciosamente, mas foi “abandonado” com razões.

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

O MonadBFT introduz um conjunto de regras rigorosas e claras de processamento de cabeçalho de cadeia ao introduzir o mecanismo de reproposta e o Certificado de Não-Endosso (NEC).

Ou finalmente comprometer-se com o bloco ‘perto de ser 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 saltar ou substituir o bloco anterior.

Este mecanismo garante que qualquer bloco que tenha recebido uma 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 limitar o comportamento de saltar impróprio.

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

Do ponto de vista do incentivo econômico, este design fornece uma clara proteção para os validadores:

• Desde que o bloco seja honestamente proposto e receba apoio na votação, a sua recompensa não será privada devido a falhas subsequentes.
• Mesmo em situações extremas, como quando um nó deliberadamente pula sua própria rodada de propostas e tenta ajudar outros a aproveitar 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 uma complexidade de comunicação alta (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 timeout, reproposições de blocos) é apenas iniciada quando a visualização falha ou existem anomalias. No caminho regular onde a maioria dos líderes honestos produz blocos continuamente, 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 em relação aos seus protocolos antecessores.

Resumo

Este artigo analisa o mecanismo básico do consenso tradicional PBFT, organiza o caminho de desenvolvimento do protocolo HotStuff e concentra-se em como o MonadBFT resolve o problema inerente do garfo de cauda da tubagem HotStuff na estrutura de camadas do protocolo.

Os garfos traseiros podem distorcer os incentivos econômicos dos proponentes de blocos e representar uma ameaça potencial para 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 reproposta e Certificado Não-Endossado (NEC).

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

1）Finalidade Especulativa
2）Resposta otimista

Análise adicional desses mecanismos e sua importância prática para validadores e desenvolvedores.

Declaração:

1. Este artigo foi reproduzido de [michael_lwy], os direitos de autor pertencem ao autor original [michael_lwy]，se tiver alguma objeção à reimpressão, por favor contacte Equipa Gate Learn)，a equipa tratará dela o mais rapidamente possível de acordo com o processo relevante.
2. Aviso Legal: As opiniões expressas neste artigo são exclusivamente do autor e não constituem qualquer conselho de investimento.
3. As outras versões do artigo são traduzidas pela equipe Gate Learn, sem mencionarGateNão copie, distribua ou plágie artigos traduzidos sem permissão.