EmParte 1,examinamos como funciona o consenso clássico PBFT e como as versões anteriores do HotStuff operam. Também analisamos como o MonadBFT resolve o problema de tail-forking do HotStuff, que é um problema em que blocos válidos às vezes são deixados para trás em sistemas pipeline.

Esse problema de bifurcação de cauda cria dois grandes problemas: 1) bagunça as recompensas para construtores de blocos honestos e 2) pode potencialmente parar a rede.

MonadBFT introduz a regra de Reproposal e os mecanismos de voto sem endosso para eliminar o problema do tail-forking, garantindo que qualquer bloco devidamente aprovado por um proponente honesto sempre entrará na cadeia.

Na parte 2, exploramos as outras duas características do MonadBFT, que são 1) finalidade especulativa e 2) responsividade otimista. Também vamos explorar as implicações do MonadBFT para os desenvolvedores.

Finalidade especulativa de uma rodada

Além da resistência ao garfo da cauda, outra característica importante do MonadBFT é a finalidade especulativa dentro de uma única rodada.

Em termos práticos, isso significa que os clientes e usuários podem receber uma confirmação para sua transação imediatamente após um bloco receber uma supermaioria de votos, mesmo antes de a próxima rodada ser concluída.

Lembre-se de que nos protocolos baseline HotStuff, um bloco geralmente não é considerado final (irreversível) até passar por pelo menos duas fases (por exemplo, Fast-Hotstuff & Diem-BFT): uma fase para obter um Certificado de Quórum (bloquear o bloco com ≥2f+1 votos) e uma segunda fase em que o próximo líder constrói com base nesse QC e compromete o bloco.

Esse compromisso de duas fases é necessário para garantir a segurança: uma vez que nodes honestos suficientes tenham bloqueado um bloco, nenhum bloco conflitante pode reunir um quórum, e o compromisso na próxima rodada o torna permanente. Portanto, normalmente, um cliente pode ter que esperar pelo próximo bloco ou próxima rodada ser produzido antes de saber que a transação anterior é final.

O MonadBFT basicamente permite que uma transação seja considerada final o suficiente (segura para agir) após apenas uma rodada de votação. Isso é chamado de finalidade especulativa.

Quando um líder propõe um bloco e os validadores votam para formar um QC para esse bloco, esse bloco agora está em um estado Votado (está bloqueado por um quórum). No MonadBFT, os validadores executarão as transações do bloco assim que formarem o QC e até enviarão uma confirmação preliminar aos clientes indicando que o bloco está (especulativamente) aceito. Isso é como dizer: 'Temos uma supermaioria concordando com este bloco. A menos que algo muito inesperado aconteça, considere este bloco confirmado.'

Essa confirmação imediata é otimista. O bloco ainda não foi confirmado no livro-razão. Isso acontecerá quando a próxima proposta chegar e finalizá-lo (QC-on QC), mas sob condições normais, nada irá revogá-lo. O único cenário que pode reverter um bloco executado de forma especulativa é se o líder se equivocou (ou seja, propôs dois blocos diferentes na mesma altura para dividir o voto).

Você pode pensar na finalidade especulativa como um bom subproduto da resistência ao fork da cauda. A resistência ao fork da cauda garante que mesmo se o próximo líder falhar, a proposta atual não será abandonada (graças às regras de reproposta e NEC). Assim, a única vez que um bloco executado de forma especulativa é descartado é se o proponente original equivocar-se (falha de assinatura dupla que é comprovadamente maliciosa), o que é: 1) detectável por meio de CQs conflitantes, 2) passível de punição e 3) extremamente raro.

Em protocolos anteriores, não garantiam que o próximo líder reprovasse o bloco anterior, então a bifurcação de cauda era possível, quebrando as suposições de especulação.

Responsividade otimista

Na maioria dos protocolos de consenso, há uma espera embutida após cada rodada, como um período de buffer ou tempo limite. Isso é para garantir que todas as mensagens tenham chegado antes de avançar. É um mecanismo de proteção destinado a lidar com o pior cenário, como quando um líder falha ou não envia nada.

Esses timeouts geralmente são excessivamente conservadores. Se a rede estiver funcionando normalmente e todos os validadores estiverem se comportando corretamente, essa espera fixa se torna uma sobrecarga desnecessária. Os blocos poderiam ter sido finalizados mais rapidamente, mas o protocolo segurou apenas por precaução.

O MonadBFT introduz responsividade otimista, o que significa que o protocolo pode avançar imediatamente com base em mensagens de rede, em vez de sempre depender de timers fixos. O princípio de design aqui pode ser resumido como "rápido quando pode, paciente quando deve".

MonadBFT é projetado de tal forma que, tanto no caso normal quanto mesmo na recuperação de uma falha, ele não pausa por um tempo determinado se não for necessário.

• No caminho feliz (significa que temos um líder honesto): Não há atraso incorporado na proposição ou votação. Assim que um líder tem a vez, ele propõe um bloco. Assim que os validadores recebem uma proposta válida, eles votam. No momento em que o líder (ou melhor, o próximo líder, já que os votos vão para o próximo proponente no HotStuff em pipeline) coleta 2f+1 votos, o QC é formado e pode ser disseminado. Em um design otimisticamente responsivo, isso aciona imediatamente a próxima fase.

Na prática, isso significa que se a latência da rede entre os nós for, digamos, 100ms, o consenso pode potencialmente concluir uma rodada em apenas alguns centenas de milissegundos (mais sobrecarga de computação e agregação).

Não espera, por exemplo, um “tempo de slot” completo de um segundo se não precisar. Isto contrasta com a mainnet do Ethereum, que segue ummodelo de slot e épocaNo Ethereum, a produção de blocos é fixada em intervalos de 12 segundos. Mesmo que todos estejam prontos mais cedo, o protocolo espera.

A abordagem do MonadBFT elimina atrasos desnecessários. Ele mantém a estrutura pipelined do HotStuff, mas remove a regra rígida de 'você deve esperar Δ segundos' no caso normal. Isso significa que pode superar sistemas limitados pelo tempo em termos de responsividade sem sacrificar a segurança.

• No caminho infeliz (falha do líder): Em muitos protocolos de consenso, quando um líder falha em propor um bloco, outros nós só percebem isso após um tempo limite Δ ter passado. Se Δ for, por exemplo, 1 segundo, esse tempo é essencialmente perdido. O MonadBFT lida com isso de forma diferente. Quando os validadores detectam uma proposta ausente, eles imediatamente transmitem mensagens de tempo limite (TC ou Certificado de Tempo limite). Assim que 2f+1 desses tempos limite são vistos, o próximo líder assume. A transição para a nova visualização é desencadeada por evidências baseadas em quórum, não pelo relógio.

Comparação com o consenso da família hotstuff

MonadBFT baseia-se na linhagem dos protocolos de consenso da família HotStuff, mas destaca-se ao alcançar uma combinação de propriedades desejáveis que nenhum design anterior conseguiu integrar completamente sem compromissos. Protocolos anteriores eram frequentemente otimizados para algumas dimensões como throughput em pipeline ou comunicação linear, mas tinham que sacrificar outras. MonadBFT consegue combinar de forma única complexidade de mensagens linear, compromissos em pipeline, resistência forte a bifurcações de cauda, responsividade instantânea sem atrasos fixos e mecanismos de recuperação eficientes, tudo isso preservando finalidade rápida e garantias de alta vivacidade. A tabela abaixo resume como o MonadBFT se compara a outros protocolos de BFT com líder rotativo nessas dimensões críticas:

O que isso significa para desenvolvedores e usuários?

Para os desenvolvedores, MonadBFT significa algumas coisas:

• Modelo de Finalidade Mais Simples: Com MonadBFT, você pode tratar um bloco que possui um QC (voto de supermaioria) como efetivamente finalizado para a maioria dos fins, porque o protocolo o finalizará ou cortará se não. Os desenvolvedores podem agir com segurança em confirmações de 1 bloco com alta confiança.
• Melhoria da experiência do usuário para aplicativos: Se você está desenvolvendo um aplicativo de alta taxa de transferência (exchange, jogo, etc.), a baixa latência e a resistência a bifurcações do MonadBFT se traduzem em uma experiência do usuário mais suave. Os usuários veem suas ações confirmadas quase que instantaneamente e não costumam encontrar reorganizações ou rollback confusos. Isso permite que você projete aplicativos que presumem finalidade e atualizações rápidas.
• Comportamento Determinístico: As regras mais rígidas do MonadBFT (como a exigência de reproposição) reduzem o não determinismo na inclusão de blocos. Há menos cenários de 'casos limite' onde um bloco pode ser incluído ou ignorado dependendo do timing sutil, como se um voto ou um timeout alcançou o líder primeiro. O MonadBFT substitui essa ambiguidade sensível ao tempo por regras explícitas e evidências verificáveis. Isso torna mais fácil raciocinar sobre a correção do protocolo e testá-lo. Também fornece bases claras para identificar nós com falhas (por exemplo, se alguém falhar em repropor ou propor um bloco conflitante, você sabe que violaram o protocolo).
• Margem de escalabilidade: Se você é um desenvolvedor preocupado com a escalabilidade, o MonadBFT oferece mais margem antes de atingir gargalos. Você pode aumentar os tamanhos dos blocos ou o número de validadores de forma mais confortável do que em um protocolo quadrático. E recursos como disseminação de blocos com codificação de apagamento significam que você pode enviar muitos dados pela rede sem sobrecarregar nós individuais. Isso torna possível mirar uma maior taxa de transferência, abrindo espaço de design para aplicações on-chain mais ambiciosas

Para os usuários finais: Um usuário comum não saberá nada sobre nada do que discutimos aqui, mas sente seus efeitos. Com o MonadBFT sustentando o Monad a cadeia, os usuários podem esperar todas as boas qualidades abaixo sem sacrificar a descentralização e a resistência à censura.

• Confirmações mais rápidas: Transações (como o envio de tokens, troca de ativos, cunhagem de NFTs, execução de negociações) serão confirmadas muito rapidamente.
• Menos Surpresas: A consistência do estado da cadeia é maior, pois coisas como tail-forking, que é essencialmente uma reorganização, são eliminadas
• Justiça e Transparência: Melhorias no consenso significam indiretamente que a operação da cadeia é mais justa. Nenhum validador único pode facilmente censurar transações ou brincar com a ordenação entre blocos.

Conclusão

Para recapitular, o MonadBFT introduz quatro inovações fundamentais em cima do consenso estilo HotStuff com pipeline:

Resistência ao Tail-Forking: MonadBFT é o primeiro protocolo BFT em pipeline a eliminar ataques de tail-forking. Isso é alcançado exigindo que o próximo líder reproponha o último bloco votado se o líder anterior falhar, ou então mostre um Certificado de Não-Endosso (NEC) como prova de que o bloco não tinha suporte. Isso garante que nenhum bloco endossado por uma supermaioria será abandonado, protegendo as recompensas dos líderes honestos e prevenindo reorganizações maliciosas e extração de MEV entre blocos.

Finalidade Especulativa em Uma Rodada: Os validadores podem confirmar um bloco após uma única rodada de comunicação (uma proposta de líder e votos), dando aos clientes uma garantia imediata de inclusão. Esta confirmação especulativa só será revertida se o líder se equivocar (um ato que pode ser comprovado e punido), tornando-se uma suposição segura na prática.

Responsividade otimista: O protocolo opera na velocidade da rede sem atrasos inerentes. Os líderes avançam com o consenso assim que os votos necessários são recebidos, e as alterações de visualização ocorrem assim que um quórum de expirações é observado, em vez de esperar por um intervalo de tempo fixo. Este design responsivo de forma otimista minimiza os tempos de espera e maximiza a capacidade de processamento, enquanto ainda lida robustamente com asincronia e falhas quando ocorrem.

Comunicação Linear: No caminho feliz (significando que o líder é honesto), a complexidade da mensagem e autenticação é linear no número de validadores. O MonadBFT mantém o padrão de comunicação eficiente do HotStuff, usando assinaturas agregadas e transmissões simples do líder para os validadores, o que permite que o protocolo escale para centenas de validadores sem gargalos de desempenho.

Aviso Legal：

1. Este artigo é reproduzido de [michael_lwy]. Todos os direitos autorais pertencem ao autor original [michael_lwy]. Se houver objeções a esta reimpressão, entre em contato com oGate Learnequipe e eles vão lidar com isso prontamente.
2. Isenção de Responsabilidade: As visões e opiniões expressas neste artigo são exclusivamente do autor e não constituem qualquer conselho de investimento.
3. As traduções do artigo para outros idiomas são feitas pela equipe Gate Learn. Salvo indicação em contrário, copiar, distribuir ou plagiar os artigos traduzidos é proibido.