O núcleo do Blockchain reside na implementação de um consenso global rigoroso (strict global consensus): ou seja, não importa onde os nós da rede estão distribuídos, em qual país ou fuso horário, todos os participantes devem finalmente chegar a um consenso sobre um conjunto de resultados objetivos.
Mas a rede distribuída na realidade não é ideal: há nós que ficam offline, há nós que mentem e até há pessoas que deliberadamente causam danos. Nesses casos, como é que o sistema consegue "consenso" e mantém a consistência?
Este é o problema que o protocolo de consenso procura resolver. Essencialmente, é um conjunto de regras que orienta um grupo de nós independentes entre si, e mesmo não completamente confiáveis, sobre como chegar a uma decisão unificada sobre a ordem e o conteúdo de cada transação.
E uma vez que esse "consenso rigoroso" seja estabelecido, a Blockchain pode desbloquear muitas características chave, como a proteção da propriedade digital, um modelo monetário resistente à inflação e uma estrutura de colaboração social escalável. Mas, para isso, o protocolo de consenso deve garantir simultaneamente dois fundamentos básicos:
Não podem ser confirmados dois blocos que se contradizem.
A rede deve continuar a avançar, não pode ficar presa ou parada.
MonadBFT é o mais recente avanço tecnológico feito nesta direção.
Revisão breve da evolução do protocolo de consenso
O mecanismo de consenso neste campo já foi estudado durante décadas. Os primeiros protocolos, como o PBFT (Tolerância a Falhas Bizantinas Práticas), já conseguem lidar com uma situação muito realista: mesmo que haja alguns nós na rede que falhem, cometam fraudes ou digam disparates, desde que não ultrapassem 1/3 do total, o sistema ainda consegue alcançar um consenso.
A forma de design desses protocolos iniciais é relativamente "tradicional": a cada rodada, um líder é escolhido, que inicia a proposta, e os outros validadores votam em múltiplas rodadas, confirmando gradualmente a ordem das transações.
Todo o processo de votação geralmente passa por várias fases, como pre-prepare, prepare, commit e reply. Em cada fase, todos os validadores precisam se comunicar entre si. Em outras palavras, todos precisam falar com todos uma vez, e a quantidade de mensagens aumenta de forma "emaranhada".
A complexidade da estrutura de comunicação é n² — ou seja, se houver 100 validadores na rede, cada rodada de consenso pode precisar transmitir quase 10 mil mensagens.
Isto não é um grande problema em redes pequenas, mas uma vez que o número de validadores aumenta, a carga de comunicação do sistema rapidamente se torna insuportável, e a eficiência cai drasticamente.
Esta estrutura de comunicação secundária de "cada um precisa se comunicar com todos" é, na verdade, muito ineficiente. Por exemplo, em uma rede com 100 validadores, cada rodada de consenso pode ter que processar milhares de mensagens.
Isso pode funcionar em um pequeno círculo, mas quando colocado em uma rede blockchain aberta e global, a carga de comunicação logo se torna inaceitável. Assim, protocolos BFT iniciais como PBFT e Tendermint geralmente são usados apenas em cenários com permissão (rede permissionada) ou em sistemas com um número muito pequeno de validadores, onde conseguem funcionar minimamente.
Para permitir que o protocolo BFT também se adapte a ambientes de blockchain públicos e sem permissão, alguns designs de nova geração começaram a adotar formas de comunicação mais leves: fazendo com que cada validador se comunique apenas com o líder, em vez de todos se comunicarem entre si.
Isto reduziu a complexidade da mensagem de n² para n —— aliviando significativamente a carga do sistema.
O protocolo HotStuff foi proposto em 2018, precisamente para resolver esse problema de escalabilidade. Sua filosofia de design é muito clara: substituir o complexo processo de votação do PBFT por uma estrutura de comunicação mais simples e liderada.
A principal característica do HotStuff é a chamada comunicação linear (linear communication). Em seu mecanismo, cada validador precisa apenas enviar seu voto ao líder atual, que então empacota esses votos e gera um Quorum Certificate (QC, certificado de maioria legal).
Este QC é essencialmente uma assinatura coletiva, que prova para toda a rede: "A maioria dos nós concordou com esta proposta."
Em comparação, o modo de comunicação do PBFT é "broadcast para todos", onde todos falam no grupo, o que pode ser bastante caótico. O modo do HotStuff é mais como "uma pessoa coleta, uma vez empacota", independentemente de quantas pessoas há na rede, consegue manter uma operação eficiente.
Além da comunicação linear, o HotStuff também pode ser atualizado para uma versão em pipeline (pipelined HotStuff), a fim de aumentar a eficiência.
No HotStuff original, o mesmo validador atua como líder em várias rodadas consecutivas, até que um bloco seja completamente confirmado. Este processo é "processar um bloco por rodada", com toda a atenção focada em avançar o bloco atual.
E na linha de produção HotStuff, o mecanismo é ainda mais flexível: a cada rodada um novo líder é escolhido, e a tarefa de cada líder tem duas partes:
Um lado empacota os votos da rodada anterior em um Quorum Certificate (QC) e transmite para toda a rede;
Propondo um novo bloco, preparando para iniciar a próxima rodada.
Ou seja, não é mais "confirmar um antes de processar o próximo", mas sim como uma linha de produção, onde diferentes líderes se alternam na responsabilidade de cada etapa. O anterior propõe um bloco, o seguinte confirma-o e continua a propor novos blocos, e o consenso na blockchain é passado adiante como uma corrida de revezamento.
Esta é a origem da metáfora "linha de montagem": o bloco atual ainda está passando pelo processo de confirmação, enquanto o próximo já está em preparação, com múltiplos passos em paralelo, aumentando a eficiência do throughput.
Resumindo, protocolos como o HotStuff fazem melhorias significativas em duas dimensões em comparação com o BFT tradicional:
Primeiro, a comunicação é mais leve, cada validador só precisa se comunicar com o líder;
Em segundo lugar, a eficiência de processamento é maior, pois vários processos de confirmação de blocos podem ser realizados em paralelo.
Isto fez do HotStuff um modelo de design para muitos mecanismos de consenso de Blockchain PoS modernos. Mas como em tudo, há vantagens e desvantagens — embora a estrutura em pipeline tenha um desempenho robusto, também introduz silenciosamente um risco estrutural que não é fácil de ser detectado.
A seguir, vamos aprofundar-nos nesta questão central: Forking de Cauda.
Problema de bifurcação de cauda (Tail-Forking)
Embora o HotStuff — especialmente a sua versão em pipeline — resolva o problema de escalabilidade dos protocolos de consenso, ele também introduz alguns novos desafios. O mais crítico, e também o mais fácil de ser ignorado, é o chamado problema de "Tail Forking".
O que é um fork de cauda? Pode ser entendido simplesmente como: uma reorganização inesperada de blocos ocorreu na "cauda" da Blockchain (reorg).
Especificamente, há um bloco que é válido, já foi propagado com sucesso para a maioria dos validadores e recebeu apoio de votos suficientes. Portanto, ele deveria ser confirmado e escrito na cadeia principal. Mas, no final, ele foi "pulada", descartado (orphaned), sendo substituído por outro novo bloco no mesmo nível.
Isso não é um Bug, nem um ataque, mas sim porque na estrutura de design do próprio protocolo, existe essa possibilidade de "queda de bloco". Isso não soa um pouco injusto? Então, como isso acontece?
Falámos anteriormente que cada líder da linha de produção HotStuff tem duas tarefas:
A. Propor um novo bloco (por exemplo Bₙ₊₁)
B. Coletar votos para o bloco do líder anterior, gerando QC (por exemplo, completando a confirmação final para Bₙ)
Essas duas tarefas são paralelas, alternando-se. Mas o problema está aqui.
Por exemplo: suponha que Alice é a líder, e ela propôs o bloco Bₙ na altura n, que obteve o voto da supermaioria e já está "quase confirmado". Em seguida, Bob deve assumir a liderança e continuar a avançar para o próximo bloco Bₙ₊₁, enquanto também deve incluir o QC (prova de maioria legal) de Bₙ em sua proposta, completando a confirmação final de Bₙ.
Mas se o Bob estiver offline neste momento, ou se não submeter intencionalmente o QC de Bₙ, então haverá um problema.
Porque ninguém completou o QC de empacotamento do bloco da Alice, o registro de votação de Bₙ não conseguiu se espalhar, e este bloco que deveria ter sido confirmado foi "tratado como frio" e, no final, foi ignorado por toda a rede.
Esta é a essência do fork final: o bloco do líder anterior é ignorado devido à negligência ou má-fé do próximo líder.
Por que a bifurcação final é tão grave?
O problema da bifurcação no final concentra-se em duas áreas principais: 1) o mecanismo de incentivo é comprometido, 2) a atividade do sistema está ameaçada.
Primeiro, a recompensa é engolida: um bloco que é descartado, o líder que o propôs não receberá nenhuma recompensa. Seja a recompensa por criar o bloco ou a taxa de transação. Por exemplo, se Alice propôs um bloco legítimo e obteve o apoio da supermaioria dos votos, mas devido a um erro ou ação maliciosa de Bob, esse bloco não foi confirmado, Alice não receberá nada no final. Isso levará a uma estrutura de incentivos errada: nós maliciosos como Bob podem "interromper" a fonte de recompensas de seus oponentes ao pular seus blocos. Esse comportamento não requer um ataque técnico, apenas uma "falta de cooperação" intencional é suficiente para enfraquecer os ganhos dos concorrentes. Se isso acontecer repetidamente, ao longo do tempo, a participação e a equidade de todo o sistema diminuirão, podendo até incitar conluios entre os nós.
Em segundo lugar, o espaço de ataque MEV se expande: O garfo de cauda também representa um problema mais insidioso, mas sério: o MEV (Valor Máximo Extraível) tem mais espaço para ser manipulado maliciosamente. Aqui está um exemplo: digamos que Alice tem um comércio de arbitragem valioso em seu bloco. Se Bob quiser criar problemas, ele pode entrar em conluio com a próxima líder, Carol, e deliberadamente não espalhar o bloqueio de Alice. Carol então reconstrói um novo bloco na mesma altura, "roubando" o comércio de arbitragem original de Alice - fazendo o MEV ganhar o seu. Esta prática de "rearranjo da cabeça da cadeia + conluio e apropriação" ainda é um bloqueio de acordo com as regras na superfície, mas na verdade é um saque bem concebido. Pior ainda, induz ao "conluio" entre líderes, transformando a confirmação em bloco num jogo de partilha de benefícios e não num serviço público.
Terceiro, a destruição da garantia de finalização afeta a experiência do usuário: Comparado aos protocolos do tipo Nakamoto, uma grande vantagem do BFT é a finalização determinística: uma vez que um bloco é submetido, não pode ser revertido. No entanto, a ramificação final destrói essa garantia, especialmente em blocos que "já receberam votos, mas ainda não foram formalmente confirmados". Certos dapps de alta capacidade de processamento geralmente desejam poder ler os dados imediatamente após a aprovação do voto do bloco para reduzir a latência, e se esse bloco for repentinamente descartado, pode resultar em um retrocesso no estado do usuário - por exemplo, saldos de contas anômalos, transações de alta alavancagem recém-concluídas desaparecendo sem motivo, estado do jogo sendo repentinamente redefinido, etc.
Quarto, pode causar falhas em cadeia: Em geral, uma bifurcação na parte final pode apenas atrasar a confirmação de um bloco, o impacto não é grande. Mas em alguns cenários extremos, se vários líderes consecutivos optarem por ignorar o bloco anterior, o sistema pode entrar em um estado de estagnação, onde ninguém está disposto a "receber" o bloco anterior. O avanço de toda a cadeia fica assim bloqueado, até que finalmente apareça um líder "disposto a assumir a responsabilidade", e a rede poderá continuar.
Embora já tenham existido algumas soluções anteriores, como o mecanismo de evasão de bifurcações finais proposto pelo protocolo BeeGees, muitas vezes é necessário sacrificar o desempenho, como a reintegração da complexidade de comunicação secundária, o que não compensa.
O que é MonadBFT?
MonadBFT é um novo protocolo de consenso projetado especificamente para resolver o problema de bifurcação no final. Sua grande vantagem é que, ao resolver riscos estruturais, não sacrifica as vantagens de desempenho trazidas pelo HotStuff em pipeline. Em outras palavras, o MonadBFT não está começando do zero, mas sim otimizando com base na estrutura central do HotStuff. Ele mantém três características-chave:
Liderança rotativa (rotating leader): em cada rodada, um novo líder é escolhido para avançar a cadeia;
Submissões em pipeline (pipelined commits): vários processos de confirmação de blocos podem ocorrer de forma sobreposta;
Comunicação linear (linear messaging): cada validador precisa apenas se comunicar com o líder, economizando uma grande quantidade de sobrecarga de rede.
Mas apenas com esses três pontos, ainda não é seguro. Para fechar a vulnerabilidade estrutural da bifurcação de cauda, o MonadBFT adicionou dois mecanismos chave:
Mecanismo de Re-Proposta (Re-Proposal)
Certificado Sem Endosse (NEC, No-Endorsement Certificate)
Mecanismo de Re-Proposta
No protocolo BFT, o tempo é dividido em rodadas (chamadas de view), e cada rodada tem um líder responsável por propor um novo bloco. Se o líder falhar (por exemplo, não apresentar o bloco a tempo ou se a proposta for inválida), o sistema mudará para a próxima rodada e escolherá um novo líder.
MonadBFT adicionou um mecanismo que garante que, durante a troca de view, qualquer bloco proposto de forma honesta não será "perdido" devido à rotação de líderes.
Quando o líder atual falha, os validadores enviam uma mensagem de mudança de vista assinada, indicando que a rodada atual expirou.
Particularmente, esta mensagem não apenas indica "tempo esgotado", mas também deve conter informações sobre o bloco da última votação desse validador, o que equivale a dizer: "Não recebi uma proposta válida, este é o último bloco que vejo."
Os novos líderes coletarão essas mensagens de timeout de um supermaioria (2f+1) de validadores e as combinarão em um Certificado de Timeout (Timeout Certificate, TC). Este TC representa: quando a rodada anterior falhou, um instantâneo da percepção unificada da rede sobre o "bloco de cabeçalho da cadeia". O novo líder escolherá o bloco de maior altura (ou o número de visão mais recente), conhecido como high_tip.
Requisitos do MonadBFT: a proposta do novo líder deve incluir um TC válido e deve re-propor o bloco pendente mais alto no TC, dando a esse bloco mais uma chance de ser confirmado.
Por quê? Como mencionamos anteriormente: não queremos que um bloco prestes a ser confirmado desapareça.
Por exemplo: suponha que Alice seja a líder da view 5, tenha proposto um bloco válido e recebido a maioria dos votos. A seguir, o líder da view 6, Bob, ficou offline e não conseguiu avançar o processo da cadeia. Quando Carol assumiu como líder da view 7, de acordo com as regras do MonadBFT, ela deve incluir TC e repropôr o bloco de Alice. Assim, o trabalho honesto de Alice não será em vão.
Se Carol não tiver o bloco da Alice, ela pode solicitar de outros nós. Os nós podem:
Fornecer o Bloco, ou
Retornar uma mensagem "sem endosse" assinada (No-Endorsement, NE), indicando que não possui este bloco (mecanismo descrito adiante). (Até f nós bizantinos podem optar por ignorar o pedido, sem responder.)
Uma vez que Carol reapresente o bloco da Alice, ela receberá uma oportunidade adicional de proposta, garantindo que não seja penalizada por falhas do líder anterior.
O papel deste mecanismo de re-proposta é claro: garantir que o avanço da cadeia seja justo e que qualquer trabalho válido não seja descartado silenciosamente devido a má sorte ou a alguém que cause problemas.
Certificado Sem Endosse (NEC)
Continuando o exemplo anterior: após o tempo limite da rodada de Bob, Carol solicita a outros validadores que forneçam o bloco high_tip (ou seja, o bloco de Alice). Neste momento, pelo menos 2f+1 validadores responderão:
Forneça o bloco da Alice
Ou envie uma mensagem NE assinada, indicando que você não recebeu o bloco da Alice.
Assim que Carol receber o bloco de Alice, ela deve repropor de acordo com as regras. Carol só pode pular esse bloco e propor um novo caso pelo menos f+1 validadores tenham assinado a mensagem NE.
Por que f+1? Em um sistema BFT composto por 3f+1 validadores, no máximo f pode ser malicioso. Se o bloco da Alice realmente recebeu o voto da supermaioria, então pelo menos 2f+1 nós honestos o receberam.
Portanto, se Carol afirmar "não consigo obter o bloco da Alice", ela deve apresentar f+1 assinaturas de validadores, provando que essas pessoas não receberam. Isso constitui um Certificado Sem Endosse (No-Endorsement Certificate, NEC).
NEC é o certificado de "isenção" do líder: é uma prova verificável que indica que o bloco anterior ainda não está pronto para ser confirmado, não foi pulado maliciosamente, mas sim "renunciado" de forma fundamentada.
Reproposição + Certificado sem endosse = Solução de bifurcação final
MonadBFT estabelece um conjunto rigoroso e claro de regras de processamento de cabeçalho de cadeia através da introdução do mecanismo de Re-Proposal e do Certificado Sem Endosse (NEC, No-Endorsement Certificate):
Deve-se ou completar a submissão final do bloco que está "perto de ser confirmado"; ou fornecer provas suficientes para demonstrar que esse bloco ainda não possui as condições para ser confirmado, caso contrário, não é permitido pular ou substituir o bloco anterior.
Este mecanismo garante que: qualquer bloco que tenha obtido uma votação de maioria legal não será abandonado devido a erros do líder ou evasão intencional. O risco estrutural de bifurcação na cauda é sistematicamente resolvido, e o protocolo pode impor restrições claras a comportamentos de salto indevido.
Se um líder tentar pular o bloco anterior sem motivo, mas não fornecer a prova NEC, o protocolo irá imediatamente identificar e rejeitar essa ação. O salto sem evidência criptográfica será considerado ilegal e não receberá o apoio do consenso da rede.
Do ponto de vista do incentivo econômico, este design oferece uma proteção clara aos validadores:
Desde que seja um bloco apresentado de forma honesta e que receba apoio por votação, a sua recompensa não será retirada devido a falhas em etapas subsequentes;
Mesmo em situações extremas, como quando um nó deliberadamente pula sua rodada de proposta, tentando ajudar outros a capturar o MEV do bloco anterior, o protocolo forçará os líderes subsequentes a reproporem o bloco original, impedindo que os atacantes obtenham ganhos econômicos ao pular o processo.
Mais importante ainda, o MonadBFT não sacrificou o desempenho do protocolo para aumentar a segurança.
Alguns designs anteriores para lidar com bifurcações de cauda (como o protocolo BeeGees) embora possuam alguma capacidade de proteção, muitas vezes dependem de alta complexidade de comunicação (n²) ou ativam processos de comunicação pesada a cada rodada, o que, na prática, aumenta significativamente a carga do sistema.
A estratégia de design do MonadBFT é mais sofisticada:
A comunicação adicional (como mensagens de tempo limite, reapresentação de blocos) só deve ser iniciada em caso de falha de visualização ou anomalias. No caminho regular da maioria dos líderes honestos que produzem blocos consecutivamente, o protocolo ainda mantém um estado de funcionamento leve e eficiente.
Este equilíbrio dinâmico entre desempenho e segurança é uma das principais vantagens do MonadBFT em comparação com os protocolos anteriores.
Resumo
Este artigo revisita os mecanismos básicos do consenso PBFT tradicional, traçando o caminho de desenvolvimento do protocolo HotStuff, e explica em detalhes como o MonadBFT resolve, a partir da estrutura da camada de protocolo, o problema de bifurcação final inerente ao HotStuff em pipeline.
A bifurcação no final distorce os incentivos econômicos do proponente do bloco e representa uma ameaça potencial à atividade da rede. MonadBFT garante que qualquer bloco proposto por líderes honestos e que receba a votação da maioria legal não será abandonado ou pulado, introduzindo um mecanismo de reproposição e Certificados Sem Endosse (NEC).
No próximo artigo, vamos continuar a explorar mais duas características centrais do MonadBFT:
Finalidade Especulativa
Responsividade Otimista
E analisar ainda mais o significado prático desses mecanismos para os validadores e desenvolvedores.
Continua.
Ver original
O conteúdo é apenas para referência, não uma solicitação ou oferta. Nenhum aconselhamento fiscal, de investimento ou jurídico é fornecido. Consulte a isenção de responsabilidade para obter mais informações sobre riscos.
MonadBFT análise (parte 1): como resolver o problema da forquilha final
O núcleo do Blockchain reside na implementação de um consenso global rigoroso (strict global consensus): ou seja, não importa onde os nós da rede estão distribuídos, em qual país ou fuso horário, todos os participantes devem finalmente chegar a um consenso sobre um conjunto de resultados objetivos.
Mas a rede distribuída na realidade não é ideal: há nós que ficam offline, há nós que mentem e até há pessoas que deliberadamente causam danos. Nesses casos, como é que o sistema consegue "consenso" e mantém a consistência?
Este é o problema que o protocolo de consenso procura resolver. Essencialmente, é um conjunto de regras que orienta um grupo de nós independentes entre si, e mesmo não completamente confiáveis, sobre como chegar a uma decisão unificada sobre a ordem e o conteúdo de cada transação.
E uma vez que esse "consenso rigoroso" seja estabelecido, a Blockchain pode desbloquear muitas características chave, como a proteção da propriedade digital, um modelo monetário resistente à inflação e uma estrutura de colaboração social escalável. Mas, para isso, o protocolo de consenso deve garantir simultaneamente dois fundamentos básicos:
Não podem ser confirmados dois blocos que se contradizem.
A rede deve continuar a avançar, não pode ficar presa ou parada.
MonadBFT é o mais recente avanço tecnológico feito nesta direção.
Revisão breve da evolução do protocolo de consenso
O mecanismo de consenso neste campo já foi estudado durante décadas. Os primeiros protocolos, como o PBFT (Tolerância a Falhas Bizantinas Práticas), já conseguem lidar com uma situação muito realista: mesmo que haja alguns nós na rede que falhem, cometam fraudes ou digam disparates, desde que não ultrapassem 1/3 do total, o sistema ainda consegue alcançar um consenso.
A forma de design desses protocolos iniciais é relativamente "tradicional": a cada rodada, um líder é escolhido, que inicia a proposta, e os outros validadores votam em múltiplas rodadas, confirmando gradualmente a ordem das transações.
Todo o processo de votação geralmente passa por várias fases, como pre-prepare, prepare, commit e reply. Em cada fase, todos os validadores precisam se comunicar entre si. Em outras palavras, todos precisam falar com todos uma vez, e a quantidade de mensagens aumenta de forma "emaranhada".
A complexidade da estrutura de comunicação é n² — ou seja, se houver 100 validadores na rede, cada rodada de consenso pode precisar transmitir quase 10 mil mensagens.
Isto não é um grande problema em redes pequenas, mas uma vez que o número de validadores aumenta, a carga de comunicação do sistema rapidamente se torna insuportável, e a eficiência cai drasticamente.
Esta estrutura de comunicação secundária de "cada um precisa se comunicar com todos" é, na verdade, muito ineficiente. Por exemplo, em uma rede com 100 validadores, cada rodada de consenso pode ter que processar milhares de mensagens.
Isso pode funcionar em um pequeno círculo, mas quando colocado em uma rede blockchain aberta e global, a carga de comunicação logo se torna inaceitável. Assim, protocolos BFT iniciais como PBFT e Tendermint geralmente são usados apenas em cenários com permissão (rede permissionada) ou em sistemas com um número muito pequeno de validadores, onde conseguem funcionar minimamente.
Para permitir que o protocolo BFT também se adapte a ambientes de blockchain públicos e sem permissão, alguns designs de nova geração começaram a adotar formas de comunicação mais leves: fazendo com que cada validador se comunique apenas com o líder, em vez de todos se comunicarem entre si.
Isto reduziu a complexidade da mensagem de n² para n —— aliviando significativamente a carga do sistema.
O protocolo HotStuff foi proposto em 2018, precisamente para resolver esse problema de escalabilidade. Sua filosofia de design é muito clara: substituir o complexo processo de votação do PBFT por uma estrutura de comunicação mais simples e liderada.
A principal característica do HotStuff é a chamada comunicação linear (linear communication). Em seu mecanismo, cada validador precisa apenas enviar seu voto ao líder atual, que então empacota esses votos e gera um Quorum Certificate (QC, certificado de maioria legal).
Este QC é essencialmente uma assinatura coletiva, que prova para toda a rede: "A maioria dos nós concordou com esta proposta."
Em comparação, o modo de comunicação do PBFT é "broadcast para todos", onde todos falam no grupo, o que pode ser bastante caótico. O modo do HotStuff é mais como "uma pessoa coleta, uma vez empacota", independentemente de quantas pessoas há na rede, consegue manter uma operação eficiente.
Além da comunicação linear, o HotStuff também pode ser atualizado para uma versão em pipeline (pipelined HotStuff), a fim de aumentar a eficiência.
No HotStuff original, o mesmo validador atua como líder em várias rodadas consecutivas, até que um bloco seja completamente confirmado. Este processo é "processar um bloco por rodada", com toda a atenção focada em avançar o bloco atual.
E na linha de produção HotStuff, o mecanismo é ainda mais flexível: a cada rodada um novo líder é escolhido, e a tarefa de cada líder tem duas partes:
Um lado empacota os votos da rodada anterior em um Quorum Certificate (QC) e transmite para toda a rede;
Propondo um novo bloco, preparando para iniciar a próxima rodada.
Ou seja, não é mais "confirmar um antes de processar o próximo", mas sim como uma linha de produção, onde diferentes líderes se alternam na responsabilidade de cada etapa. O anterior propõe um bloco, o seguinte confirma-o e continua a propor novos blocos, e o consenso na blockchain é passado adiante como uma corrida de revezamento.
Esta é a origem da metáfora "linha de montagem": o bloco atual ainda está passando pelo processo de confirmação, enquanto o próximo já está em preparação, com múltiplos passos em paralelo, aumentando a eficiência do throughput.
Resumindo, protocolos como o HotStuff fazem melhorias significativas em duas dimensões em comparação com o BFT tradicional:
Primeiro, a comunicação é mais leve, cada validador só precisa se comunicar com o líder;
Em segundo lugar, a eficiência de processamento é maior, pois vários processos de confirmação de blocos podem ser realizados em paralelo.
Isto fez do HotStuff um modelo de design para muitos mecanismos de consenso de Blockchain PoS modernos. Mas como em tudo, há vantagens e desvantagens — embora a estrutura em pipeline tenha um desempenho robusto, também introduz silenciosamente um risco estrutural que não é fácil de ser detectado.
A seguir, vamos aprofundar-nos nesta questão central: Forking de Cauda.
Problema de bifurcação de cauda (Tail-Forking)
Embora o HotStuff — especialmente a sua versão em pipeline — resolva o problema de escalabilidade dos protocolos de consenso, ele também introduz alguns novos desafios. O mais crítico, e também o mais fácil de ser ignorado, é o chamado problema de "Tail Forking".
O que é um fork de cauda? Pode ser entendido simplesmente como: uma reorganização inesperada de blocos ocorreu na "cauda" da Blockchain (reorg).
Especificamente, há um bloco que é válido, já foi propagado com sucesso para a maioria dos validadores e recebeu apoio de votos suficientes. Portanto, ele deveria ser confirmado e escrito na cadeia principal. Mas, no final, ele foi "pulada", descartado (orphaned), sendo substituído por outro novo bloco no mesmo nível.
Isso não é um Bug, nem um ataque, mas sim porque na estrutura de design do próprio protocolo, existe essa possibilidade de "queda de bloco". Isso não soa um pouco injusto? Então, como isso acontece?
Falámos anteriormente que cada líder da linha de produção HotStuff tem duas tarefas:
A. Propor um novo bloco (por exemplo Bₙ₊₁)
B. Coletar votos para o bloco do líder anterior, gerando QC (por exemplo, completando a confirmação final para Bₙ)
Essas duas tarefas são paralelas, alternando-se. Mas o problema está aqui.
Por exemplo: suponha que Alice é a líder, e ela propôs o bloco Bₙ na altura n, que obteve o voto da supermaioria e já está "quase confirmado". Em seguida, Bob deve assumir a liderança e continuar a avançar para o próximo bloco Bₙ₊₁, enquanto também deve incluir o QC (prova de maioria legal) de Bₙ em sua proposta, completando a confirmação final de Bₙ.
Mas se o Bob estiver offline neste momento, ou se não submeter intencionalmente o QC de Bₙ, então haverá um problema.
Porque ninguém completou o QC de empacotamento do bloco da Alice, o registro de votação de Bₙ não conseguiu se espalhar, e este bloco que deveria ter sido confirmado foi "tratado como frio" e, no final, foi ignorado por toda a rede.
Esta é a essência do fork final: o bloco do líder anterior é ignorado devido à negligência ou má-fé do próximo líder.
Por que a bifurcação final é tão grave?
O problema da bifurcação no final concentra-se em duas áreas principais: 1) o mecanismo de incentivo é comprometido, 2) a atividade do sistema está ameaçada.
Primeiro, a recompensa é engolida: um bloco que é descartado, o líder que o propôs não receberá nenhuma recompensa. Seja a recompensa por criar o bloco ou a taxa de transação. Por exemplo, se Alice propôs um bloco legítimo e obteve o apoio da supermaioria dos votos, mas devido a um erro ou ação maliciosa de Bob, esse bloco não foi confirmado, Alice não receberá nada no final. Isso levará a uma estrutura de incentivos errada: nós maliciosos como Bob podem "interromper" a fonte de recompensas de seus oponentes ao pular seus blocos. Esse comportamento não requer um ataque técnico, apenas uma "falta de cooperação" intencional é suficiente para enfraquecer os ganhos dos concorrentes. Se isso acontecer repetidamente, ao longo do tempo, a participação e a equidade de todo o sistema diminuirão, podendo até incitar conluios entre os nós.
Em segundo lugar, o espaço de ataque MEV se expande: O garfo de cauda também representa um problema mais insidioso, mas sério: o MEV (Valor Máximo Extraível) tem mais espaço para ser manipulado maliciosamente. Aqui está um exemplo: digamos que Alice tem um comércio de arbitragem valioso em seu bloco. Se Bob quiser criar problemas, ele pode entrar em conluio com a próxima líder, Carol, e deliberadamente não espalhar o bloqueio de Alice. Carol então reconstrói um novo bloco na mesma altura, "roubando" o comércio de arbitragem original de Alice - fazendo o MEV ganhar o seu. Esta prática de "rearranjo da cabeça da cadeia + conluio e apropriação" ainda é um bloqueio de acordo com as regras na superfície, mas na verdade é um saque bem concebido. Pior ainda, induz ao "conluio" entre líderes, transformando a confirmação em bloco num jogo de partilha de benefícios e não num serviço público.
Terceiro, a destruição da garantia de finalização afeta a experiência do usuário: Comparado aos protocolos do tipo Nakamoto, uma grande vantagem do BFT é a finalização determinística: uma vez que um bloco é submetido, não pode ser revertido. No entanto, a ramificação final destrói essa garantia, especialmente em blocos que "já receberam votos, mas ainda não foram formalmente confirmados". Certos dapps de alta capacidade de processamento geralmente desejam poder ler os dados imediatamente após a aprovação do voto do bloco para reduzir a latência, e se esse bloco for repentinamente descartado, pode resultar em um retrocesso no estado do usuário - por exemplo, saldos de contas anômalos, transações de alta alavancagem recém-concluídas desaparecendo sem motivo, estado do jogo sendo repentinamente redefinido, etc.
Quarto, pode causar falhas em cadeia: Em geral, uma bifurcação na parte final pode apenas atrasar a confirmação de um bloco, o impacto não é grande. Mas em alguns cenários extremos, se vários líderes consecutivos optarem por ignorar o bloco anterior, o sistema pode entrar em um estado de estagnação, onde ninguém está disposto a "receber" o bloco anterior. O avanço de toda a cadeia fica assim bloqueado, até que finalmente apareça um líder "disposto a assumir a responsabilidade", e a rede poderá continuar.
Embora já tenham existido algumas soluções anteriores, como o mecanismo de evasão de bifurcações finais proposto pelo protocolo BeeGees, muitas vezes é necessário sacrificar o desempenho, como a reintegração da complexidade de comunicação secundária, o que não compensa.
O que é MonadBFT?
MonadBFT é um novo protocolo de consenso projetado especificamente para resolver o problema de bifurcação no final. Sua grande vantagem é que, ao resolver riscos estruturais, não sacrifica as vantagens de desempenho trazidas pelo HotStuff em pipeline. Em outras palavras, o MonadBFT não está começando do zero, mas sim otimizando com base na estrutura central do HotStuff. Ele mantém três características-chave:
Liderança rotativa (rotating leader): em cada rodada, um novo líder é escolhido para avançar a cadeia;
Submissões em pipeline (pipelined commits): vários processos de confirmação de blocos podem ocorrer de forma sobreposta;
Comunicação linear (linear messaging): cada validador precisa apenas se comunicar com o líder, economizando uma grande quantidade de sobrecarga de rede.
Mas apenas com esses três pontos, ainda não é seguro. Para fechar a vulnerabilidade estrutural da bifurcação de cauda, o MonadBFT adicionou dois mecanismos chave:
Mecanismo de Re-Proposta (Re-Proposal)
Certificado Sem Endosse (NEC, No-Endorsement Certificate)
Mecanismo de Re-Proposta
No protocolo BFT, o tempo é dividido em rodadas (chamadas de view), e cada rodada tem um líder responsável por propor um novo bloco. Se o líder falhar (por exemplo, não apresentar o bloco a tempo ou se a proposta for inválida), o sistema mudará para a próxima rodada e escolherá um novo líder.
MonadBFT adicionou um mecanismo que garante que, durante a troca de view, qualquer bloco proposto de forma honesta não será "perdido" devido à rotação de líderes.
Quando o líder atual falha, os validadores enviam uma mensagem de mudança de vista assinada, indicando que a rodada atual expirou.
Particularmente, esta mensagem não apenas indica "tempo esgotado", mas também deve conter informações sobre o bloco da última votação desse validador, o que equivale a dizer: "Não recebi uma proposta válida, este é o último bloco que vejo."
Os novos líderes coletarão essas mensagens de timeout de um supermaioria (2f+1) de validadores e as combinarão em um Certificado de Timeout (Timeout Certificate, TC). Este TC representa: quando a rodada anterior falhou, um instantâneo da percepção unificada da rede sobre o "bloco de cabeçalho da cadeia". O novo líder escolherá o bloco de maior altura (ou o número de visão mais recente), conhecido como high_tip.
Requisitos do MonadBFT: a proposta do novo líder deve incluir um TC válido e deve re-propor o bloco pendente mais alto no TC, dando a esse bloco mais uma chance de ser confirmado.
Por quê? Como mencionamos anteriormente: não queremos que um bloco prestes a ser confirmado desapareça.
Por exemplo: suponha que Alice seja a líder da view 5, tenha proposto um bloco válido e recebido a maioria dos votos. A seguir, o líder da view 6, Bob, ficou offline e não conseguiu avançar o processo da cadeia. Quando Carol assumiu como líder da view 7, de acordo com as regras do MonadBFT, ela deve incluir TC e repropôr o bloco de Alice. Assim, o trabalho honesto de Alice não será em vão.
Se Carol não tiver o bloco da Alice, ela pode solicitar de outros nós. Os nós podem:
Fornecer o Bloco, ou
Retornar uma mensagem "sem endosse" assinada (No-Endorsement, NE), indicando que não possui este bloco (mecanismo descrito adiante). (Até f nós bizantinos podem optar por ignorar o pedido, sem responder.)
Uma vez que Carol reapresente o bloco da Alice, ela receberá uma oportunidade adicional de proposta, garantindo que não seja penalizada por falhas do líder anterior.
O papel deste mecanismo de re-proposta é claro: garantir que o avanço da cadeia seja justo e que qualquer trabalho válido não seja descartado silenciosamente devido a má sorte ou a alguém que cause problemas.
Certificado Sem Endosse (NEC)
Continuando o exemplo anterior: após o tempo limite da rodada de Bob, Carol solicita a outros validadores que forneçam o bloco high_tip (ou seja, o bloco de Alice). Neste momento, pelo menos 2f+1 validadores responderão:
Forneça o bloco da Alice
Ou envie uma mensagem NE assinada, indicando que você não recebeu o bloco da Alice.
Assim que Carol receber o bloco de Alice, ela deve repropor de acordo com as regras. Carol só pode pular esse bloco e propor um novo caso pelo menos f+1 validadores tenham assinado a mensagem NE.
Por que f+1? Em um sistema BFT composto por 3f+1 validadores, no máximo f pode ser malicioso. Se o bloco da Alice realmente recebeu o voto da supermaioria, então pelo menos 2f+1 nós honestos o receberam.
Portanto, se Carol afirmar "não consigo obter o bloco da Alice", ela deve apresentar f+1 assinaturas de validadores, provando que essas pessoas não receberam. Isso constitui um Certificado Sem Endosse (No-Endorsement Certificate, NEC).
NEC é o certificado de "isenção" do líder: é uma prova verificável que indica que o bloco anterior ainda não está pronto para ser confirmado, não foi pulado maliciosamente, mas sim "renunciado" de forma fundamentada.
Reproposição + Certificado sem endosse = Solução de bifurcação final
MonadBFT estabelece um conjunto rigoroso e claro de regras de processamento de cabeçalho de cadeia através da introdução do mecanismo de Re-Proposal e do Certificado Sem Endosse (NEC, No-Endorsement Certificate):
Deve-se ou completar a submissão final do bloco que está "perto de ser confirmado"; ou fornecer provas suficientes para demonstrar que esse bloco ainda não possui as condições para ser confirmado, caso contrário, não é permitido pular ou substituir o bloco anterior.
Este mecanismo garante que: qualquer bloco que tenha obtido uma votação de maioria legal não será abandonado devido a erros do líder ou evasão intencional. O risco estrutural de bifurcação na cauda é sistematicamente resolvido, e o protocolo pode impor restrições claras a comportamentos de salto indevido.
Se um líder tentar pular o bloco anterior sem motivo, mas não fornecer a prova NEC, o protocolo irá imediatamente identificar e rejeitar essa ação. O salto sem evidência criptográfica será considerado ilegal e não receberá o apoio do consenso da rede.
Do ponto de vista do incentivo econômico, este design oferece uma proteção clara aos validadores:
Desde que seja um bloco apresentado de forma honesta e que receba apoio por votação, a sua recompensa não será retirada devido a falhas em etapas subsequentes;
Mesmo em situações extremas, como quando um nó deliberadamente pula sua rodada de proposta, tentando ajudar outros a capturar o MEV do bloco anterior, o protocolo forçará os líderes subsequentes a reproporem o bloco original, impedindo que os atacantes obtenham ganhos econômicos ao pular o processo.
Mais importante ainda, o MonadBFT não sacrificou o desempenho do protocolo para aumentar a segurança.
Alguns designs anteriores para lidar com bifurcações de cauda (como o protocolo BeeGees) embora possuam alguma capacidade de proteção, muitas vezes dependem de alta complexidade de comunicação (n²) ou ativam processos de comunicação pesada a cada rodada, o que, na prática, aumenta significativamente a carga do sistema.
A estratégia de design do MonadBFT é mais sofisticada:
A comunicação adicional (como mensagens de tempo limite, reapresentação de blocos) só deve ser iniciada em caso de falha de visualização ou anomalias. No caminho regular da maioria dos líderes honestos que produzem blocos consecutivamente, o protocolo ainda mantém um estado de funcionamento leve e eficiente.
Este equilíbrio dinâmico entre desempenho e segurança é uma das principais vantagens do MonadBFT em comparação com os protocolos anteriores.
Resumo
Este artigo revisita os mecanismos básicos do consenso PBFT tradicional, traçando o caminho de desenvolvimento do protocolo HotStuff, e explica em detalhes como o MonadBFT resolve, a partir da estrutura da camada de protocolo, o problema de bifurcação final inerente ao HotStuff em pipeline.
A bifurcação no final distorce os incentivos econômicos do proponente do bloco e representa uma ameaça potencial à atividade da rede. MonadBFT garante que qualquer bloco proposto por líderes honestos e que receba a votação da maioria legal não será abandonado ou pulado, introduzindo um mecanismo de reproposição e Certificados Sem Endosse (NEC).
No próximo artigo, vamos continuar a explorar mais duas características centrais do MonadBFT:
Finalidade Especulativa
Responsividade Otimista
E analisar ainda mais o significado prático desses mecanismos para os validadores e desenvolvedores.
Continua.