EmParte 1,analisamos como funciona o consenso clássico PBFT e como as versões anteriores do HotStuff operam. Também observamos como o MonadBFT resolve o problema de bifurcação de cauda do HotStuff, onde blocos válidos às vezes são deixados para trás em sistemas em pipeline.

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

O MonadBFT introduz a regra Reproposal e os mecanismos de voto No-Endorsement para eliminar o problema do tail-forking, garantindo que qualquer bloco devidamente aprovado por um proponente honesto sempre chegará à cadeia.

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

Finalidade especulativa de uma rodada

Para além da resistência a bifurcações de 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 sobre esse CQ e compromete o bloco.

Esta confirmação em duas fases é necessária para garantir a segurança: uma vez que nodes honestos suficientes tenham bloqueado um bloco, nenhum bloco conflituoso consegue reunir um quórum, e a confirmação na próxima rodada torna-a permanente. Assim, normalmente, um cliente pode ter de esperar pelo próximo bloco ou próxima rodada a ser produzida antes de saber que a transação anterior é final.

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 está agora num 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é mesmo enviarão uma confirmação preliminar aos clientes indicando que o bloco está (especulativamente) aceite. Isto é como dizer: 'Temos uma supermaioria concordando com este bloco. A menos que algo muito inesperado aconteça, considere este bloco confirmado.'

Esta 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 o revogará. O único cenário que pode reverter um bloco executado especulativamente é se o líder equivocou (ou seja, propôs dois blocos diferentes na mesma altura para dividir o voto).

Pode pensar na finalidade especulativa como um bom subproduto da resistência à bifurcação de cauda. A resistência à bifurcação de cauda garante que, mesmo que o próximo líder falhe, a proposta atual não será abandonada (graças às regras de reproposta e NEC). Portanto, a única vez que um bloco executado de forma especulativa é descartado é se o proponente original equivocar-se (falha de dupla assinatura que é comprovadamente maliciosa), o que é: 1) detetável através de QCs conflitantes, 2) punível e 3) extremamente raro.

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

Responsividade otimista

Na maioria dos protocolos de consenso, existe um intervalo embutido 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.

Estes timeouts são frequentemente excessivamente conservadores. Se a rede estiver a funcionar normalmente e todos os validadores estiverem a comportar-se corretamente, essa espera fixa torna-se um overhead desnecessário. Os blocos poderiam ter sido finalizados mais rapidamente, mas o protocolo recuou apenas no caso de.

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

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

• No caminho feliz (significa que temos um líder honesto): Não há atraso incorporado na proposta ou votação. Assim que um líder tem a vez, 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, QC é formado e pode ser disseminado. Em um design otimisticamente responsivo, isso desencadeia imediatamente a próxima fase.

Na prática, isso significa que se a latência de rede entre os nós for, digamos, 100ms, o consenso pode potencialmente terminar uma rodada em apenas um par de centenas de milissegundos (além do overhead de computação e agregação).

Não espera, por exemplo, um segundo completo de “tempo de slot” se não for necessário. Isto contrasta com a mainnet do Ethereum que segue ummodelo de slot e época. Na 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 "você deve esperar Δ segundos" no caso normal. Isso significa que pode superar sistemas vinculados ao tempo em termos de capacidade de resposta 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 depois que um timeout Δ passou. Se Δ for, por exemplo, 1 segundo, esse tempo é essencialmente perdido. O MonadBFT lida com isso de forma diferente. Quando os validadores detectam uma proposta em falta, eles imediatamente transmitem mensagens de timeout (TC ou Certificado de Timeout). Assim que 2f+1 desses timeouts são vistos, o próximo líder assume. A transição para a nova visão é desencadeada por evidências baseadas em quórum, não pelo relógio.

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

O MonadBFT baseia-se na linhagem dos protocolos de consenso da família HotStuff, mas destaca-se por alcançar uma combinação de propriedades desejáveis que nenhum design anterior foi capaz de integrar completamente sem compromissos. Protocolos anteriores eram frequentemente otimizados para algumas dimensões, como a taxa de transferência em pipeline ou comunicação linear, mas tinham que sacrificar outras. O MonadBFT consegue combinar de forma única a complexidade de mensagens lineares, commits em pipeline, resistência forte ao tail-forking, capacidade de resposta instantânea sem atrasos fixos e mecanismos de recuperação eficientes, preservando ao mesmo tempo a 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 em relação a essas dimensões críticas:

O que significa isto para os programadores e utilizadores?

Para os desenvolvedores, MonadBFT significa algumas coisas:

• Modelo de Finalidade Mais Simples: Com o MonadBFT, você pode tratar um bloco que tenha um QC (voto de maioria) como efetivamente finalizado para a maioria dos fins, porque o protocolo irá finalizá-lo 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 utilizador para aplicações: Se está a desenvolver uma aplicação de alto débito (bolsa, jogo, etc.), a baixa latência e resistência a bifurcações do MonadBFT traduzem-se numa experiência mais suave para o utilizador. Os utilizadores veem as suas ações confirmadas quase instantaneamente e não costumam deparar-se com reorganizações ou reversões confusas. Isto permite-lhe projetar aplicações que assumem a finalidade e atualizações rápidas.
• Comportamento Determinístico: As regras mais rígidas do MonadBFT (como a exigência de reproposta) reduzem o não determinismo na inclusão de blocos. Existem menos cenários de "casos especiais" onde um bloco pode ser incluído ou ignorado dependendo do timing sutil, como se um voto ou um timeout alcançasse primeiro o líder. O MonadBFT substitui tal 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 defeituosos (por exemplo, se alguém não repropor ou propõe um bloco conflitante, você sabe que violaram o protocolo).
• Margem de escalabilidade: Se você é um desenvolvedor preocupado com a escala, o MonadBFT oferece mais margem antes de atingir gargalos. Você pode aumentar o tamanho 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 codificados por apagamento significam que você pode enviar muitos dados através da rede sem sobrecarregar nós individuais. Isso torna possível mirar em maior throughput, abrindo espaço de design para aplicações on-chain mais ambiciosas.

Para os Utilizadores Finais: Um utilizador comum não terá conhecimento de nada do que discutimos aqui, mas sente os seus efeitos. Com o MonadBFT a sustentar o Monad na cadeia, os utilizadores podem esperar todas as boas qualidades abaixo sem sacrificar a descentralização e a resistência à censura.

• Confirmações mais rápidas: As transações (como enviar tokens, trocar ativos, criar NFTs, executar 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
• Equidade 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 manipular a ordem entre blocos.

Conclusão

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

Resistência ao Tail-Forking: O MonadBFT é o primeiro protocolo BFT em pipeline a eliminar ataques de tail-forking. Ele consegue isso ao exigir que o próximo líder reproponha o último bloco votado se o líder anterior falhar, ou 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 seja abandonado, protegendo as recompensas de líderes honestos e evitando reorganizações maliciosas e extração de MEV entre blocos.

Finalidade Especulativa num Único Round: Os validadores podem confirmar um bloco após um único round de comunicação (uma proposta de líder e votos), dando aos clientes uma garantia imediata de inclusão. Esta confirmação especulativa apenas será revertida se o líder equivocar-se (um ato que pode ser provado e punido), tornando-a uma suposição segura na prática.

Responsividade otimista: O protocolo opera à 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 são visualizadas assim que um quórum de tempos limite é observado, em vez de esperar por um intervalo de tempo fixo. Este design otimista e responsivo minimiza os tempos de espera e maximiza o débito, lidando ainda de forma robusta com assincronia 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 eficiente de comunicação do HotStuff, usando assinaturas agregadas e transmissões simples do líder para os validadores, o que permite ao protocolo escalar 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]michael_lwy]. Se houver objeções a esta reimpressão, por favor contacte oGate Learnequipa, e eles tratarão disso prontamente.
2. Aviso de responsabilidade: As opiniões expressas neste artigo são exclusivamente as 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, é proibido copiar, distribuir ou plagiar os artigos traduzidos.