O núcleo da blockchain está em realizar um consenso global rigoroso (strict global consensus): ou seja, independentemente de onde os nós da rede estejam distribuídos, em que país ou fuso horário, todos os participantes devem finalmente chegar a um acordo sobre um conjunto de resultados objetivos.
Mas a rede distribuída na realidade não é ideal: há nós que caem, há nós que mentem e até há pessoas que deliberadamente causam danos. Nessa situação, como é que o sistema consegue "unanimidade" e mantém a consistência?
Este é o problema que o protocolo de consenso visa resolver. É essencialmente um conjunto de regras que orienta um grupo de nós independentes entre si, e que podem até não ser totalmente confiáveis, sobre como chegar a um acordo unificado sobre a ordem e o conteúdo de cada transação.
E uma vez que esse "consenso rigoroso" esteja 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 a condição é que o próprio protocolo de consenso deve garantir simultaneamente dois aspectos fundamentais:
Não podem ser confirmados dois blocos que se contradizem mutuamente;
A rede deve continuar a avançar, não pode travar ou parar.
MonadBFT é o mais recente avanço tecnológico nesta direção.
Uma breve revisão da evolução dos protocolos de consenso
O campo dos mecanismos de consenso já foi estudado há várias décadas. Os primeiros protocolos, como o PBFT (Practical Byzantine Fault Tolerance), já conseguiam 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 chegar a um consenso.
O design desses protocolos iniciais é mais "tradicional": a cada rodada, um líder é escolhido para iniciar uma proposta, e os outros validadores votam nessa proposta em várias rodadas, confirmando passo a passo 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 devem comunicar-se entre si. Em outras palavras, cada um deve falar com todos, resultando em um aumento explosivo na quantidade de mensagens.
A complexidade desta estrutura de comunicação é n² - ou seja, se houver 100 validadores na rede, cada rodada de consenso pode exigir a transmissão de quase 10.000 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.
Fonte:
Esta estrutura de "cada um tem que se comunicar com cada um" na comunicação secundária é, na verdade, muito ineficiente. Por exemplo, em uma rede com 100 validadores, cada rodada de consenso pode precisar processar milhares de mensagens.
Isso pode funcionar em um pequeno círculo, mas se for colocado em uma rede global e aberta, a carga de comunicação rapidamente se torna inaceitável. Assim, protocolos BFT iniciais como PBFT e Tendermint geralmente são usados apenas em cenários de rede permitida (permissioned network) ou em sistemas com um número muito limitado de validadores, onde conseguem funcionar de forma precária.
A fim de adaptar o protocolo BFT a um ambiente de cadeia pública sem permissão, alguns designs de próxima geração começaram a se mover para uma forma mais leve de comunicação: cada validador só se comunica com o líder, em vez de todos os membros da equipe.
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. Seu conceito de design é muito claro: substituir o complexo processo de votação do PBFT por uma estrutura de comunicação mais simples e liderada.
A característica chave do HotStuff é o que se chama de comunicação linear. No seu mecanismo, cada validador só precisa enviar seu voto ao líder atual, que então empacota esses votos e gera um Certificado de Quorum (QC, prova 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 total", onde todos falam no grupo, resultando em uma situação bastante confusa. O modo do HotStuff é mais parecido com "uma pessoa coleta, uma vez empacota", independentemente de quantas pessoas estão na rede, ainda consegue operar de forma eficiente.
A imagem acima compara a estrutura de comunicação em difusão do HotStuff com o modo de interconexão total do PBFT.
Fonte:
Além da comunicação linear, o HotStuff pode ser atualizado para uma versão pipelined (pipelined HotStuff) para melhorar 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 é de "processar um bloco por rodada", concentrando toda a energia em avançar aquele específico.
E na linha de montagem HotStuff, o mecanismo torna-se ainda mais flexível: a cada rodada, um novo líder é escolhido, e as tarefas de cada líder são duas:
Enquanto empacota o voto da rodada anterior em um Quorum Certificate (QC) e o transmite para toda a rede;
Propõe um novo bloco, preparando-se 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 revezam na responsabilidade de 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á passando pelo processo de confirmação, e o próximo já está em preparação, com várias etapas em paralelo para melhorar a eficiência do rendimento.
Em resumo, protocolos como o HotStuff fizeram melhorias significativas em duas dimensões em comparação com o BFT tradicional:
Em primeiro lugar, a comunicação é mais leve, cada validador só precisa comunicar-se com o líder;
Em segundo lugar, a eficiência de processamento é maior, pois vários processos de confirmação de blocos podem ocorrer em paralelo.
Isso fez com que o HotStuff se tornasse um modelo de design para muitos mecanismos de consenso de blockchain PoS modernos. Mas como tudo tem seus prós e contras - embora a estrutura em pipeline tenha um desempenho forte, ela também introduziu silenciosamente um risco estrutural que não é fácil de detectar.
A seguir, vamos discutir em profundidade esta questão central: Forking de Cauda (Tail Forking).
Problema de bifurcação final (Tail-Forking)
Embora o HotStuff — especialmente a sua versão em pipeline — resolva o problema de escalabilidade dos protocolos de consenso, ele também traz alguns novos desafios. O mais crítico, e também o mais fácil de ser ignorado, é o que se chama de problema de "Tail Forking".
O que é um fork de cauda? Pode ser entendido de forma simples 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 suficiente. Em teoria, ele deveria ser confirmado e escrito na cadeia principal. Mas, no final, ele foi "pulada", descartada (orphaned), substituída por outro novo bloco na mesma altura.
Isso não é um bug, nem um ataque, mas sim devido à estrutura de design do protocolo em si, que existe a possibilidade de "perda de conexão". Isso não soa um pouco injusto? Então, como isso acontece?
Já mencionamos 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 do bloco do líder anterior, gerar QC (por exemplo, completar a confirmação final para Bₙ)
Estas duas tarefas são paralelas, alternando-se em revezamento. Mas o problema está aqui.
Por exemplo: suponha que Alice seja a líder, ela propôs o bloco Bₙ na altura n, e este bloco recebeu votos de supermaioria, estando "quase confirmado".
A seguir, Bob deve assumir a liderança e continuar a avançar para o próximo bloco da cadeia Bₙ₊₁, enquanto também deve empacotar o QC (prova de maioria legal) de Bₙ na sua proposta, completando a confirmação final de Bₙ.
Mas se o Bob estiver offline neste momento, ou deliberadamente não submeter o QC de Bₙ, então haverá um problema.
Porque ninguém completou a QC do bloco da Alice, o registo de votação de Bₙ não conseguiu ser propagado, e este bloco que deveria ter sido confirmado foi "tratado como frio", acabando por ser 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 severa?
Os problemas de bifurcação no final concentram-se em duas áreas principais: 1) o mecanismo de incentivo é comprometido, 2) a atividade do sistema está ameaçada.
Primeiro, a recompensa foi absorvida:
Se um bloco for descartado, o seu proponente não receberá nenhuma recompensa. Nem recompensa por bloco nem taxas de transação. Por exemplo, se Alice propuser um bloco legítimo e conseguir o apoio de uma supermaioria de votos, mas por erro ou ação maliciosa de Bob, esse bloco não for confirmado, Alice não receberá nenhum centavo. Isso levará a uma estrutura de incentivos errada: nós maliciosos como Bob podem "cortar" a fonte de recompensas dos concorrentes ao ignorar os blocos deles. Esse comportamento não requer um ataque técnico, basta uma "não cooperação" intencional para minar 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 nós.
Em segundo lugar, o espaço para ataques MEV se ampliou:
A bifurcação na parte final também pode trazer um problema mais oculto, mas sério: o espaço para a manipulação maliciosa do MEV (Valor Máximo Extraível) aumentou. Por exemplo: suponha que o bloco de Alice contenha uma negociação de arbitragem extremamente valiosa. Se Bob tiver a intenção de causar problemas, ele pode combinar com o próximo líder, Carol, para não divulgar o bloco de Alice intencionalmente. Então, Carol poderá reconstruir um novo bloco na mesma altura, "roubando" a negociação de arbitragem originalmente de Alice — transformando os ganhos de MEV em seus próprios. Essa prática de "reorganização da cadeia + apropriação combinada" parece, à primeira vista, estar de acordo com as regras de criação de blocos, mas na verdade é um saque cuidadosamente planejado. Pior ainda, isso pode induzir os líderes a estabelecerem uma "relação de conluio", fazendo com que a confirmação de blocos se torne um jogo de distribuição de interesses, em vez de um serviço público.
Terceiro, comprometer a garantia de finalização, afetar a experiência do usuário:
Comparado aos protocolos do tipo Nakamoto, uma grande vantagem do BFT é o fim determinístico: uma vez que um bloco é submetido, não pode ser revertido. No entanto, a bifurcação final compromete essa garantia, especialmente em blocos que "receberam votos, mas ainda não foram formalmente confirmados". Certos dapps de alta capacidade normalmente desejam poder ler os dados imediatamente após a votação do bloco ser aprovada para reduzir a latência, e se esse bloco for repentinamente descartado, pode resultar em um retrocesso no estado do usuário - por exemplo, saldo da conta anômalo, negociações de alta alavancagem recém-finalizadas desaparecendo sem explicação, estado do jogo sendo redefinido repentinamente, etc.
Quarto, pode desencadear falhas em cadeia:
Em geral, bifurcações no final podem fazer com que um bloco seja confirmado com um atraso, e o impacto não é grande. No entanto, em alguns cenários extremos, se vários líderes consecutivos optarem por pular o bloco anterior, o sistema pode entrar em um estado de estagnação, onde ninguém está disposto a "assumir" o bloco anterior. O avanço de toda a cadeia fica preso até que finalmente apareça um líder "disposto a assumir a responsabilidade", momento em que a rede poderá continuar a avançar.
Embora já tenham existido algumas soluções anteriores, como o mecanismo de evasão de bifurcações finais proposto pelo protocolo BeeGees, muitas vezes isso requer sacrificar o desempenho, como a reintrodução da complexidade da 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ções finais. Sua grande vantagem é que, ao resolver riscos estruturais, não sacrifica as vantagens de desempenho trazidas pelo HotStuff em pipeline. Em outras palavras, MonadBFT não é uma reinvenção do zero, mas sim uma continuação da otimização baseada na estrutura central do HotStuff. Ele mantém três características-chave:
Rotação de líderes (rotating leader): a cada rodada, um novo líder é escolhido para avançar a cadeia;
Submissões em pipeline (pipelined commits): múltiplos processos de confirmação de blocos podem ocorrer de forma sobreposta;
Comunicação linear (linear messaging): cada validador só precisa se comunicar com o líder, economizando uma grande quantidade de largura de banda da rede.
Mas apenas com esses três pontos, ainda não é seguro o suficiente. Para fechar a vulnerabilidade estrutural do fork na parte final, o MonadBFT adicionou dois mecanismos-chave:
Mecanismo de Re-Proposta (Re-Proposal)
2）Certificado sem endosse (NEC, No-Endorsement Certificate)
Mecanismo de Reproposta (Re-Proposal)
No protocolo BFT, o tempo é dividido em rodadas (chamadas de view), onde 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 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 falhar, os validadores emitirã uma mensagem de mudança de vista assinada, indicando que a rodada atual expirou.
Em particular, esta mensagem não indica apenas que "o tempo esgotou", mas deve também incluir as informações do 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 estas mensagens de timeout de um supermajority (2f+1) de validadores e as combinarão em um certificado de timeout (Timeout Certificate, TC). Este TC representa: quando a rodada anterior falhou, uma captura de conhecimento unificada da rede sobre o "bloco de cadeia cabeça". O novo líder escolherá o bloco de maior altura (ou o número de visão mais recente), o chamado high_tip.
Requisitos do MonadBFT: A proposta do novo líder deve conter um TC válido e deve re-propor o bloco pendente mais alto no TC, para que esse bloco tenha a oportunidade de ser confirmado novamente.
Por que não? 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. Em seguida, o líder da view 6, Bob, ficou offline e não conseguiu avançar o processo da cadeia. Quando Carol assumir como líder da view 7, de acordo com as regras do MonadBFT, ela deve incluir TC e reapresentar o bloco de Alice. Assim, o trabalho honesto de Alice não será em vão.
Se Carol não tiver o bloco de Alice, ela pode solicitar de outros nós. Os nós podem:
Fornecer o bloco, ou
Retorne uma "mensagem sem endosse" (No-Endorsement, NE) assinada, indicando que não possui este bloco (a seguir explicaremos seu mecanismo). (Até f nós bizantinos podem optar por ignorar o pedido e não responder.)
Assim que Carol repropuser o bloco de Alice, ela receberá uma oportunidade adicional de proposta, garantindo que não será "punida" devido ao fracasso do líder da rodada anterior.
O objetivo deste mecanismo de re-proposta é claro: garantir que o avanço da cadeia seja justo, e que qualquer trabalho eficaz não seja descartado silenciosamente devido a má sorte ou alguém a causar problemas.
Certificado Sem Endosse (NEC)
Continuando o exemplo anterior: Após o tempo limite da rodada de Bob, Carol solicita que outros validadores forneçam o bloco high_tip (ou seja, o bloco de Alice). Neste momento, pelo menos 2f+1 validadores responderão:
ou fornecer o bloco da Alice
Ou envie uma mensagem NE assinada, indicando que não recebeu o bloco da Alice.
Assim que Carol receber o bloco de Alice, ela deve repropô-lo de acordo com as regras. Carol só pode ignorar o bloco e propor um novo se 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 f pode agir de forma maliciosa. Se o bloco da Alice realmente obteve a votação da supermaioria, então pelo menos 2f+1 nós honestos o receberam.
Assim, se Carol afirmar "não consigo obter o bloco da Alice", ela deve apresentar f+1 assinaturas de validadores para provar 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 é uma omissão maliciosa, mas sim uma "renúncia" fundamentada.
Reproposição + Certificado sem endosse = Solução para bifurcações finais
MonadBFT estabelece um conjunto rigoroso e claro de regras de processamento da cadeia através da introdução do mecanismo de Re-Proposal e do Certificado sem Endosse (NEC, No-Endorsement Certificate):
Deve-se concluir a submissão final do bloco "quase confirmado";
ou fornecer provas suficientes de que o bloco não atende às 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 a maioria legal dos votos não será abandonado devido a um erro do líder ou por evasão intencional.
Os riscos estruturais da bifurcação final são sistematicamente resolvidos, e o protocolo pode impor restrições claras a comportamentos inadequados de salto.
Se um líder tentar pular o bloco anterior sem motivo, mas não conseguir fornecer evidências de NEC, o protocolo reconhecerá e rejeitará imediatamente esse comportamento. A ação de salto sem evidência criptográfica será considerada ilegal e não receberá suporte de consenso da rede.
Do ponto de vista dos incentivos econômicos, este design oferece uma proteção clara aos validadores:
Desde que o bloco seja proposto de forma honesta e receba apoio de votos, a sua recompensa não será retirada devido a falhas nas etapas subsequentes;
Mesmo em situações extremas, como quando um determinado nó salta deliberadamente a sua rodada de propostas, tentando ajudar outros a capturar o MEV do bloco anterior, o protocolo irá forçar o líder subsequente a priorizar a reapresentação do bloco original, de modo que o atacante não consiga obter ganhos econômicos ao pular o processo.
Mais importante ainda, o MonadBFT não comprometeu o desempenho do protocolo em prol da segurança.
Alguns designs anteriores para lidar com bifurcações finais (como o protocolo BeeGees) embora possuam uma certa 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, re-propostas de blocos) só é iniciada em caso de falha de visão ou anomalias. No caminho regular em que a maioria dos líderes honestos produz blocos consecutivamente, o protocolo continua a manter um estado de operação leve e eficiente.
Este equilíbrio dinâmico entre desempenho e segurança é uma das principais vantagens do MonadBFT em relação aos protocolos anteriores.
Resumo
Este artigo revisita os mecanismos básicos do consenso PBFT tradicional, traça o caminho de desenvolvimento do protocolo HotStuff e foca na explicação de como o MonadBFT resolve, a partir da estrutura da camada do protocolo, o problema da bifurcação final inerente ao HotStuff em pipeline.
A bifurcação no final distorcerá os incentivos econômicos dos proponentes de blocos e representa uma ameaça potencial à atividade da rede. O MonadBFT, ao introduzir um mecanismo de repropaganda e certificados sem endosse (NEC), garante que qualquer bloco proposto por líderes honestos e que receba a maioria legal dos votos não será abandonado ou pulado.
No próximo artigo, continuaremos a explorar mais duas características centrais do MonadBFT:
1）Finalidade Especulativa
2）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: redefinir a segurança do consenso Blockchain, dizer adeus ao risco de forquilha na parte final
Autor: michaellwy
O núcleo da blockchain está em realizar um consenso global rigoroso (strict global consensus): ou seja, independentemente de onde os nós da rede estejam distribuídos, em que país ou fuso horário, todos os participantes devem finalmente chegar a um acordo sobre um conjunto de resultados objetivos.
Mas a rede distribuída na realidade não é ideal: há nós que caem, há nós que mentem e até há pessoas que deliberadamente causam danos. Nessa situação, como é que o sistema consegue "unanimidade" e mantém a consistência?
Este é o problema que o protocolo de consenso visa resolver. É essencialmente um conjunto de regras que orienta um grupo de nós independentes entre si, e que podem até não ser totalmente confiáveis, sobre como chegar a um acordo unificado sobre a ordem e o conteúdo de cada transação.
E uma vez que esse "consenso rigoroso" esteja 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 a condição é que o próprio protocolo de consenso deve garantir simultaneamente dois aspectos fundamentais:
Não podem ser confirmados dois blocos que se contradizem mutuamente;
A rede deve continuar a avançar, não pode travar ou parar.
MonadBFT é o mais recente avanço tecnológico nesta direção.
Uma breve revisão da evolução dos protocolos de consenso
O campo dos mecanismos de consenso já foi estudado há várias décadas. Os primeiros protocolos, como o PBFT (Practical Byzantine Fault Tolerance), já conseguiam 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 chegar a um consenso.
O design desses protocolos iniciais é mais "tradicional": a cada rodada, um líder é escolhido para iniciar uma proposta, e os outros validadores votam nessa proposta em várias rodadas, confirmando passo a passo 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 devem comunicar-se entre si. Em outras palavras, cada um deve falar com todos, resultando em um aumento explosivo na quantidade de mensagens.
A complexidade desta estrutura de comunicação é n² - ou seja, se houver 100 validadores na rede, cada rodada de consenso pode exigir a transmissão de quase 10.000 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.
Fonte:
Esta estrutura de "cada um tem que se comunicar com cada um" na comunicação secundária é, na verdade, muito ineficiente. Por exemplo, em uma rede com 100 validadores, cada rodada de consenso pode precisar processar milhares de mensagens.
Isso pode funcionar em um pequeno círculo, mas se for colocado em uma rede global e aberta, a carga de comunicação rapidamente se torna inaceitável. Assim, protocolos BFT iniciais como PBFT e Tendermint geralmente são usados apenas em cenários de rede permitida (permissioned network) ou em sistemas com um número muito limitado de validadores, onde conseguem funcionar de forma precária.
A fim de adaptar o protocolo BFT a um ambiente de cadeia pública sem permissão, alguns designs de próxima geração começaram a se mover para uma forma mais leve de comunicação: cada validador só se comunica com o líder, em vez de todos os membros da equipe.
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. Seu conceito de design é muito claro: substituir o complexo processo de votação do PBFT por uma estrutura de comunicação mais simples e liderada.
A característica chave do HotStuff é o que se chama de comunicação linear. No seu mecanismo, cada validador só precisa enviar seu voto ao líder atual, que então empacota esses votos e gera um Certificado de Quorum (QC, prova 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 total", onde todos falam no grupo, resultando em uma situação bastante confusa. O modo do HotStuff é mais parecido com "uma pessoa coleta, uma vez empacota", independentemente de quantas pessoas estão na rede, ainda consegue operar de forma eficiente.
A imagem acima compara a estrutura de comunicação em difusão do HotStuff com o modo de interconexão total do PBFT.
Fonte:
Além da comunicação linear, o HotStuff pode ser atualizado para uma versão pipelined (pipelined HotStuff) para melhorar 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 é de "processar um bloco por rodada", concentrando toda a energia em avançar aquele específico.
E na linha de montagem HotStuff, o mecanismo torna-se ainda mais flexível: a cada rodada, um novo líder é escolhido, e as tarefas de cada líder são duas:
Enquanto empacota o voto da rodada anterior em um Quorum Certificate (QC) e o transmite para toda a rede;
Propõe um novo bloco, preparando-se 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 revezam na responsabilidade de 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á passando pelo processo de confirmação, e o próximo já está em preparação, com várias etapas em paralelo para melhorar a eficiência do rendimento.
Em resumo, protocolos como o HotStuff fizeram melhorias significativas em duas dimensões em comparação com o BFT tradicional:
Em primeiro lugar, a comunicação é mais leve, cada validador só precisa comunicar-se com o líder;
Em segundo lugar, a eficiência de processamento é maior, pois vários processos de confirmação de blocos podem ocorrer em paralelo.
Isso fez com que o HotStuff se tornasse um modelo de design para muitos mecanismos de consenso de blockchain PoS modernos. Mas como tudo tem seus prós e contras - embora a estrutura em pipeline tenha um desempenho forte, ela também introduziu silenciosamente um risco estrutural que não é fácil de detectar.
A seguir, vamos discutir em profundidade esta questão central: Forking de Cauda (Tail Forking).
Problema de bifurcação final (Tail-Forking)
Embora o HotStuff — especialmente a sua versão em pipeline — resolva o problema de escalabilidade dos protocolos de consenso, ele também traz alguns novos desafios. O mais crítico, e também o mais fácil de ser ignorado, é o que se chama de problema de "Tail Forking".
O que é um fork de cauda? Pode ser entendido de forma simples 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 suficiente. Em teoria, ele deveria ser confirmado e escrito na cadeia principal. Mas, no final, ele foi "pulada", descartada (orphaned), substituída por outro novo bloco na mesma altura.
Isso não é um bug, nem um ataque, mas sim devido à estrutura de design do protocolo em si, que existe a possibilidade de "perda de conexão". Isso não soa um pouco injusto? Então, como isso acontece?
Já mencionamos 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 do bloco do líder anterior, gerar QC (por exemplo, completar a confirmação final para Bₙ)
Estas duas tarefas são paralelas, alternando-se em revezamento. Mas o problema está aqui.
Por exemplo: suponha que Alice seja a líder, ela propôs o bloco Bₙ na altura n, e este bloco recebeu votos de supermaioria, estando "quase confirmado".
A seguir, Bob deve assumir a liderança e continuar a avançar para o próximo bloco da cadeia Bₙ₊₁, enquanto também deve empacotar o QC (prova de maioria legal) de Bₙ na sua proposta, completando a confirmação final de Bₙ.
Mas se o Bob estiver offline neste momento, ou deliberadamente não submeter o QC de Bₙ, então haverá um problema.
Porque ninguém completou a QC do bloco da Alice, o registo de votação de Bₙ não conseguiu ser propagado, e este bloco que deveria ter sido confirmado foi "tratado como frio", acabando por ser 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 severa?
Os problemas de bifurcação no final concentram-se em duas áreas principais: 1) o mecanismo de incentivo é comprometido, 2) a atividade do sistema está ameaçada.
Primeiro, a recompensa foi absorvida:
Se um bloco for descartado, o seu proponente não receberá nenhuma recompensa. Nem recompensa por bloco nem taxas de transação. Por exemplo, se Alice propuser um bloco legítimo e conseguir o apoio de uma supermaioria de votos, mas por erro ou ação maliciosa de Bob, esse bloco não for confirmado, Alice não receberá nenhum centavo. Isso levará a uma estrutura de incentivos errada: nós maliciosos como Bob podem "cortar" a fonte de recompensas dos concorrentes ao ignorar os blocos deles. Esse comportamento não requer um ataque técnico, basta uma "não cooperação" intencional para minar 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 nós.
Em segundo lugar, o espaço para ataques MEV se ampliou:
A bifurcação na parte final também pode trazer um problema mais oculto, mas sério: o espaço para a manipulação maliciosa do MEV (Valor Máximo Extraível) aumentou. Por exemplo: suponha que o bloco de Alice contenha uma negociação de arbitragem extremamente valiosa. Se Bob tiver a intenção de causar problemas, ele pode combinar com o próximo líder, Carol, para não divulgar o bloco de Alice intencionalmente. Então, Carol poderá reconstruir um novo bloco na mesma altura, "roubando" a negociação de arbitragem originalmente de Alice — transformando os ganhos de MEV em seus próprios. Essa prática de "reorganização da cadeia + apropriação combinada" parece, à primeira vista, estar de acordo com as regras de criação de blocos, mas na verdade é um saque cuidadosamente planejado. Pior ainda, isso pode induzir os líderes a estabelecerem uma "relação de conluio", fazendo com que a confirmação de blocos se torne um jogo de distribuição de interesses, em vez de um serviço público.
Terceiro, comprometer a garantia de finalização, afetar a experiência do usuário:
Comparado aos protocolos do tipo Nakamoto, uma grande vantagem do BFT é o fim determinístico: uma vez que um bloco é submetido, não pode ser revertido. No entanto, a bifurcação final compromete essa garantia, especialmente em blocos que "receberam votos, mas ainda não foram formalmente confirmados". Certos dapps de alta capacidade normalmente desejam poder ler os dados imediatamente após a votação do bloco ser aprovada para reduzir a latência, e se esse bloco for repentinamente descartado, pode resultar em um retrocesso no estado do usuário - por exemplo, saldo da conta anômalo, negociações de alta alavancagem recém-finalizadas desaparecendo sem explicação, estado do jogo sendo redefinido repentinamente, etc.
Quarto, pode desencadear falhas em cadeia:
Em geral, bifurcações no final podem fazer com que um bloco seja confirmado com um atraso, e o impacto não é grande. No entanto, em alguns cenários extremos, se vários líderes consecutivos optarem por pular o bloco anterior, o sistema pode entrar em um estado de estagnação, onde ninguém está disposto a "assumir" o bloco anterior. O avanço de toda a cadeia fica preso até que finalmente apareça um líder "disposto a assumir a responsabilidade", momento em que a rede poderá continuar a avançar.
Embora já tenham existido algumas soluções anteriores, como o mecanismo de evasão de bifurcações finais proposto pelo protocolo BeeGees, muitas vezes isso requer sacrificar o desempenho, como a reintrodução da complexidade da 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ções finais. Sua grande vantagem é que, ao resolver riscos estruturais, não sacrifica as vantagens de desempenho trazidas pelo HotStuff em pipeline. Em outras palavras, MonadBFT não é uma reinvenção do zero, mas sim uma continuação da otimização baseada na estrutura central do HotStuff. Ele mantém três características-chave:
Rotação de líderes (rotating leader): a cada rodada, um novo líder é escolhido para avançar a cadeia;
Submissões em pipeline (pipelined commits): múltiplos processos de confirmação de blocos podem ocorrer de forma sobreposta;
Comunicação linear (linear messaging): cada validador só precisa se comunicar com o líder, economizando uma grande quantidade de largura de banda da rede.
Mas apenas com esses três pontos, ainda não é seguro o suficiente. Para fechar a vulnerabilidade estrutural do fork na parte final, o MonadBFT adicionou dois mecanismos-chave:
2）Certificado sem endosse (NEC, No-Endorsement Certificate)
Mecanismo de Reproposta (Re-Proposal)
No protocolo BFT, o tempo é dividido em rodadas (chamadas de view), onde 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 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 falhar, os validadores emitirã uma mensagem de mudança de vista assinada, indicando que a rodada atual expirou.
Em particular, esta mensagem não indica apenas que "o tempo esgotou", mas deve também incluir as informações do 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 estas mensagens de timeout de um supermajority (2f+1) de validadores e as combinarão em um certificado de timeout (Timeout Certificate, TC). Este TC representa: quando a rodada anterior falhou, uma captura de conhecimento unificada da rede sobre o "bloco de cadeia cabeça". O novo líder escolherá o bloco de maior altura (ou o número de visão mais recente), o chamado high_tip.
Requisitos do MonadBFT: A proposta do novo líder deve conter um TC válido e deve re-propor o bloco pendente mais alto no TC, para que esse bloco tenha a oportunidade de ser confirmado novamente.
Por que não? 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. Em seguida, o líder da view 6, Bob, ficou offline e não conseguiu avançar o processo da cadeia. Quando Carol assumir como líder da view 7, de acordo com as regras do MonadBFT, ela deve incluir TC e reapresentar o bloco de Alice. Assim, o trabalho honesto de Alice não será em vão.
Se Carol não tiver o bloco de Alice, ela pode solicitar de outros nós. Os nós podem:
Fornecer o bloco, ou
Retorne uma "mensagem sem endosse" (No-Endorsement, NE) assinada, indicando que não possui este bloco (a seguir explicaremos seu mecanismo). (Até f nós bizantinos podem optar por ignorar o pedido e não responder.)
Assim que Carol repropuser o bloco de Alice, ela receberá uma oportunidade adicional de proposta, garantindo que não será "punida" devido ao fracasso do líder da rodada anterior.
O objetivo deste mecanismo de re-proposta é claro: garantir que o avanço da cadeia seja justo, e que qualquer trabalho eficaz não seja descartado silenciosamente devido a má sorte ou alguém a causar problemas.
Certificado Sem Endosse (NEC)
Continuando o exemplo anterior: Após o tempo limite da rodada de Bob, Carol solicita que outros validadores forneçam o bloco high_tip (ou seja, o bloco de Alice). Neste momento, pelo menos 2f+1 validadores responderão:
ou fornecer o bloco da Alice
Ou envie uma mensagem NE assinada, indicando que não recebeu o bloco da Alice.
Assim que Carol receber o bloco de Alice, ela deve repropô-lo de acordo com as regras. Carol só pode ignorar o bloco e propor um novo se 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 f pode agir de forma maliciosa. Se o bloco da Alice realmente obteve a votação da supermaioria, então pelo menos 2f+1 nós honestos o receberam.
Assim, se Carol afirmar "não consigo obter o bloco da Alice", ela deve apresentar f+1 assinaturas de validadores para provar 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 é uma omissão maliciosa, mas sim uma "renúncia" fundamentada.
Reproposição + Certificado sem endosse = Solução para bifurcações finais
MonadBFT estabelece um conjunto rigoroso e claro de regras de processamento da cadeia através da introdução do mecanismo de Re-Proposal e do Certificado sem Endosse (NEC, No-Endorsement Certificate):
Deve-se concluir a submissão final do bloco "quase confirmado";
ou fornecer provas suficientes de que o bloco não atende às 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 a maioria legal dos votos não será abandonado devido a um erro do líder ou por evasão intencional.
Os riscos estruturais da bifurcação final são sistematicamente resolvidos, e o protocolo pode impor restrições claras a comportamentos inadequados de salto.
Se um líder tentar pular o bloco anterior sem motivo, mas não conseguir fornecer evidências de NEC, o protocolo reconhecerá e rejeitará imediatamente esse comportamento. A ação de salto sem evidência criptográfica será considerada ilegal e não receberá suporte de consenso da rede.
Do ponto de vista dos incentivos econômicos, este design oferece uma proteção clara aos validadores:
Desde que o bloco seja proposto de forma honesta e receba apoio de votos, a sua recompensa não será retirada devido a falhas nas etapas subsequentes;
Mesmo em situações extremas, como quando um determinado nó salta deliberadamente a sua rodada de propostas, tentando ajudar outros a capturar o MEV do bloco anterior, o protocolo irá forçar o líder subsequente a priorizar a reapresentação do bloco original, de modo que o atacante não consiga obter ganhos econômicos ao pular o processo.
Mais importante ainda, o MonadBFT não comprometeu o desempenho do protocolo em prol da segurança.
Alguns designs anteriores para lidar com bifurcações finais (como o protocolo BeeGees) embora possuam uma certa 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, re-propostas de blocos) só é iniciada em caso de falha de visão ou anomalias. No caminho regular em que a maioria dos líderes honestos produz blocos consecutivamente, o protocolo continua a manter um estado de operação leve e eficiente.
Este equilíbrio dinâmico entre desempenho e segurança é uma das principais vantagens do MonadBFT em relação aos protocolos anteriores.
Resumo
Este artigo revisita os mecanismos básicos do consenso PBFT tradicional, traça o caminho de desenvolvimento do protocolo HotStuff e foca na explicação de como o MonadBFT resolve, a partir da estrutura da camada do protocolo, o problema da bifurcação final inerente ao HotStuff em pipeline.
A bifurcação no final distorcerá os incentivos econômicos dos proponentes de blocos e representa uma ameaça potencial à atividade da rede. O MonadBFT, ao introduzir um mecanismo de repropaganda e certificados sem endosse (NEC), garante que qualquer bloco proposto por líderes honestos e que receba a maioria legal dos votos não será abandonado ou pulado.
No próximo artigo, continuaremos a explorar mais duas características centrais do MonadBFT:
1）Finalidade Especulativa
2）Responsividade Otimista
E analisar ainda mais o significado prático desses mecanismos para os validadores e desenvolvedores.
Continua.