Na primeira parte, estudamos o funcionamento do consenso PBFT clássico (tolerância a falhas bizantinas práticas) e como as versões iniciais do HotStuff operam. Também aprendemos como o MonadBFT resolve o problema de forquilha no final do HotStuff, ou seja, o problema em que blocos válidos às vezes são descartados em sistemas em pipeline.
Este problema da forquilha causa dois problemas principais: 1) Perturba as recompensas dos construtores de blocos honestos, 2) Pode levar à paragem da rede.
MonadBFT introduziu regras de re-proposta e um mecanismo de votação sem endosse para eliminar problemas de forquilha de cauda, garantindo que qualquer bloco devidamente aprovado de proponentes honestos possa entrar na cadeia.
Na segunda parte, vamos explorar mais duas características do MonadBFT: 1) finalização especulativa e 2) responsividade otimista. Também vamos discutir o impacto do MonadBFT nos desenvolvedores.
Finalidade de especulação de uma única rodada
Além de resistir a forquilha de cauda, outra característica principal do MonadBFT é a finalização de uma única rodada de especulação.
Na prática, isso significa que os clientes e usuários podem receber a confirmação da transação imediatamente após a maioria dos votos serem obtidos no bloco, mesmo antes da conclusão da próxima rodada.
Lembre-se de que, no protocolo HotStuff de referência, um bloco geralmente passa por pelo menos duas fases (como Fast-Hotstuff e Diem-BFT) antes de ser considerado finalizado (irrevogável): uma fase obtém o certificado de quórum (QC) (para bloquear o bloco com ≥2f+1 votos), a segunda fase é o próximo líder construindo e submetendo o bloco com base nesse certificado de quórum (QC).
Este compromisso em duas fases é necessário para garantir a segurança: uma vez que um número suficiente de nós honestos tenha bloqueado um bloco, o bloco em conflito não pode alcançar o quórum, e a próxima rodada de compromisso irá torná-lo permanente. Portanto, o cliente geralmente pode precisar esperar até que o próximo bloco ou a próxima rodada seja gerada para saber se a transação anterior foi finalmente confirmada.
O MonadBFT basicamente permite que as transações sejam consideradas suficientemente finais (podendo operar de forma segura) após apenas uma ronda de votação. Isso é conhecido como finalização especulativa.
Quando o líder propõe um Bloco e os validadores votam para formar o QC desse Bloco, este Bloco entra no estado de votação (já foi bloqueado pela maioria legal). No MonadBFT, assim que os validadores formam o QC, eles imediatamente executam as transações desse Bloco e podem até enviar uma confirmação preliminar ao cliente, indicando que o Bloco foi (especulativamente) aceito. É como dizer "temos a grande maioria das pessoas a concordar com este Bloco. A menos que ocorra uma situação muito inesperada, pode-se considerar que este Bloco está confirmado."
Esta confirmação instantânea é otimista. O bloco ainda não foi submetido no livro-razão. Isso acontecerá quando a próxima proposta surgir e confirmar isso (QC-on QC), mas em condições normais, nada irá revogar isso. A única situação que pode revogar um bloco de execução especulativa é quando o líder sofre um ataque equivalente (ou seja, propõe dois blocos diferentes na mesma altura para dispersar os votos).
Você pode ver a finalização especulativa como um excelente subproduto da resistência à forquilha de cauda. A resistência à forquilha de cauda garante que mesmo que o próximo líder falhe, a proposta atual não será descartada (graças à re-proposta e às regras do NEC). A única situação em que um bloco de execução especulativa é descartado é quando o proponente original sofre um ataque equivalente (um erro de dupla assinatura comprovadamente malicioso), e essa situação: 1) pode ser detectada por QC de conflito; 2) pode ser punida; 3) é extremamente rara.
Nos acordos anteriores, eles não garantem que o próximo líder irá reapresentar o bloco anterior, portanto, a forquilha final é possível, quebrando assim a hipótese de especulação.
Resposta otimista
Na maioria dos protocolos de consenso, há um período de espera embutido após cada rodada, como um período de amortecimento ou um tempo limite. Isso é para garantir que todas as mensagens tenham chegado antes de continuar a avançar. É um mecanismo de proteção destinado a lidar com as piores situações, como o colapso do líder ou a não envio de qualquer informação.
Esses prazos costumam ser excessivamente conservadores. Se a rede estiver funcionando normalmente e todos os validadores se comportarem corretamente, então a espera fixa se tornará um custo desnecessário. Os blocos poderiam ser concluídos mais rapidamente, mas o protocolo atrasou-se por precaução.
MonadBFT introduz uma resposta otimista, o que significa que o protocolo pode avançar imediatamente com base nas informações da rede, em vez de depender sempre de um temporizador fixo. O princípio de design aqui pode ser resumido como "se puder ser rápido, seja rápido; só seja paciente quando necessário".
O design do MonadBFT permite que, em condições normais e até mesmo durante a recuperação de falhas, não pause à espera de um tempo limite predefinido, a menos que seja necessário.
No caminho da felicidade (significa que temos um líder honesto): Não há atrasos embutidos nas propostas ou votações. Assim que for a vez do líder, ele propõe um bloco. Assim que o validador recebe uma proposta válida, ele vota imediatamente. Quando o líder (ou mais precisamente, o próximo líder, pois na linha de produção HotStuff, os votos são enviados ao próximo proponente) coleta 2f+1 votos, o QC é formado e pode ser propagado. Em um design de resposta otimista, isso desencadeia imediatamente a próxima fase.
Na prática, isso significa que se a latência da rede entre os nós for de 100 milissegundos, o consenso pode ser concluído em apenas algumas centenas de milissegundos para uma rodada (acrescido dos custos de cálculo e agregação).
Se não for necessário, não irá esperar, por exemplo, um "tempo de slot" de um segundo inteiro. Isso é diferente do modelo de slot e época adotado pela mainnet do Ethereum. No Ethereum, o intervalo de tempo para a produção de blocos é fixado em 12 segundos. Mesmo que todos estejam preparados com antecedência, o protocolo irá esperar.
O método MonadBFT elimina atrasos desnecessários. Ele mantém a estrutura HotStuff em pipeline, mas remove a exigência rígida de "esperar Δ segundos" que normalmente é necessária. Isso significa que pode superar sistemas com restrições de 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 o líder falha em propor um bloco, os outros nós só percebem isso após um tempo limite Δ. Por exemplo, se Δ for 1 segundo, esse tempo é basicamente desperdiçado. O tratamento do MonadBFT é diferente. Quando os validadores detectam que a proposta foi perdida, eles imediatamente transmitem uma mensagem de tempo limite (TC ou certificado de tempo limite). Assim que houver 2f+1 tempos limite, o próximo líder assume. A transição para a nova visão é desencadeada por provas baseadas na maioria, e não por um relógio.
Comparação com o consenso da família hotstuff
MonadBFT é construído sobre a base dos protocolos de consenso da série HotStuff, mas se destaca ao implementar uma combinação de uma série de características ideais. Os protocolos anteriores geralmente eram otimizados para certas dimensões, como taxa de transferência em pipeline ou comunicação linear, mas tinham que sacrificar outros aspectos. MonadBFT combina de forma única a complexidade de mensagens lineares, o envio em pipeline, uma forte resistência a forquilha de parte final, responsividade instantânea sem atraso fixo e um mecanismo de recuperação eficiente, enquanto ainda preserva a rápida determinação final e garantias de alta disponibilidade. A tabela abaixo resume a comparação entre MonadBFT e outros protocolos BFT com liderança rotativa nestas dimensões chave:
O que isso significa para os desenvolvedores e usuários?
Para os desenvolvedores, MonadBFT significa algumas coisas:
Modelo de determinação final mais simples: Com o MonadBFT, você pode considerar um bloco com QC (votação da maioria absoluta) como efetivamente finalizado, pois o protocolo irá finalizá-lo ou aplicar uma penalização. Os desenvolvedores podem operar com alta confiança de forma segura com 1 confirmação de bloco.
Melhorar a experiência do utilizador da aplicação: Se você está a construir uma aplicação de alto rendimento (como uma troca, jogos, etc.), as características de baixa latência e resistência a forquilha do MonadBFT resultarão numa experiência do utilizador mais fluída. Os utilizadores poderão praticamente ver as suas operações confirmadas de imediato, e não encontrarão frequentemente reorganizações ou retrocessos confusos. Assim, você poderá projetar uma aplicação com determinação final e atualizações rápidas.
Comportamento determinístico: As regras mais rígidas do MonadBFT, como requisitos de reproposta, reduzem a incerteza da inclusão de blocos. Há menos "casos extremos" em que os blocos são incluídos ou ignorados devido a fatores de tempo sutis, como se uma votação ou tempo limite atinge o líder primeiro. O MonadBFT substitui essa ambiguidade sensível ao tempo por regras claras e evidências verificáveis. Isso torna mais fácil inferir a correção do protocolo e testá-lo. Ele também fornece uma base clara para identificar nós defeituosos (por exemplo, se alguém não voltar a propor ou propor um bloco conflitante, você sabe que está violando o protocolo).
Espaço de escalabilidade: Se você é um desenvolvedor que se preocupa com escalabilidade, o MonadBFT oferece mais espaço para você antes de atingir um gargalo. Em comparação com protocolos secundários, você pode aumentar mais facilmente o tamanho do bloco ou o número de validadores. Além disso, funcionalidades como a propagação de blocos com codificação de apagamento significam que você pode enviar grandes quantidades de dados pela rede sem consumir excessivamente um único nó. Isso torna possível visar uma maior taxa de transferência, abrindo espaço de design para aplicações on-chain mais ambiciosas.
Para os usuários finais: Usuários comuns não entenderão nada do que estamos discutindo aqui, mas sentirão seu impacto. Com o MonadBFT como base da cadeia Monad, os usuários podem esperar todas as boas características a seguir, sem sacrificar a descentralização e resistindo à censura.
Reduzir acidentes: a consistência do estado da cadeia é maior, pois coisas que pertencem essencialmente à reorganização, como forquilhas de cauda, foram eliminadas.
Justo e transparente: A melhoria do consenso implica indiretamente que a operação da cadeia é mais justa. Nenhum único validador pode facilmente revisar transações ou manipular a ordenação entre blocos.
Conclusão
Resumindo, o MonadBFT introduziu quatro inovações centrais com base no consenso estilo HotStuff em pipeline:
Resistência a forquilha de cauda: MonadBFT é o primeiro protocolo BFT em pipeline a eliminar ataques de forquilha de cauda. Ele alcança isso ao permitir que o próximo líder repropõe o bloco da última votação no caso de falha do líder anterior, ou apresenta um Certificado Sem Endosse (NEC), provando que o bloco carece de apoio. Isso garante que qualquer bloco que receba apoio de uma ampla maioria não seja descartado, protegendo assim as recompensas dos líderes honestos e prevenindo reestruturações maliciosas e extração de MEV entre blocos.
Finalidade da especulação de uma única rodada: Os validadores podem confirmar blocos após uma comunicação de uma única rodada (um líder propõe e vota), fornecendo garantias imediatas de inclusão aos clientes. Esta confirmação especulativa só será revertida em caso de ataque equivalente do líder (um comportamento que pode ser provado e punido), tornando-se assim uma suposição de segurança na prática.
Resposta otimista: O protocolo opera à velocidade da rede, sem atrasos inerentes. O líder avança imediatamente para o consenso após receber os votos necessários, e as mudanças de vista ocorrem imediatamente após observar a expiração do quórum, em vez de esperar um intervalo de tempo fixo. Este design de resposta otimista minimiza o tempo de espera e maximiza a taxa de transferência, enquanto ainda é capaz de lidar de forma robusta em casos de assíncrono e falhas.
Comunicação linear: No caminho feliz (ou seja, quando o líder é honesto), a complexidade das mensagens e das validações tem uma relação linear com o número de validadores. O MonadBFT mantém o eficiente padrão de comunicação do HotStuff, utilizando assinaturas agregadas e a simples transmissão do líder para os validadores, permitindo que o protocolo se expanda para centenas de validadores sem apresentar gargalos de desempenho.
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 2): o que significa para desenvolvedores e usuários
Na primeira parte, estudamos o funcionamento do consenso PBFT clássico (tolerância a falhas bizantinas práticas) e como as versões iniciais do HotStuff operam. Também aprendemos como o MonadBFT resolve o problema de forquilha no final do HotStuff, ou seja, o problema em que blocos válidos às vezes são descartados em sistemas em pipeline.
Este problema da forquilha causa dois problemas principais: 1) Perturba as recompensas dos construtores de blocos honestos, 2) Pode levar à paragem da rede.
MonadBFT introduziu regras de re-proposta e um mecanismo de votação sem endosse para eliminar problemas de forquilha de cauda, garantindo que qualquer bloco devidamente aprovado de proponentes honestos possa entrar na cadeia.
Na segunda parte, vamos explorar mais duas características do MonadBFT: 1) finalização especulativa e 2) responsividade otimista. Também vamos discutir o impacto do MonadBFT nos desenvolvedores.
Finalidade de especulação de uma única rodada
Além de resistir a forquilha de cauda, outra característica principal do MonadBFT é a finalização de uma única rodada de especulação.
Na prática, isso significa que os clientes e usuários podem receber a confirmação da transação imediatamente após a maioria dos votos serem obtidos no bloco, mesmo antes da conclusão da próxima rodada.
Lembre-se de que, no protocolo HotStuff de referência, um bloco geralmente passa por pelo menos duas fases (como Fast-Hotstuff e Diem-BFT) antes de ser considerado finalizado (irrevogável): uma fase obtém o certificado de quórum (QC) (para bloquear o bloco com ≥2f+1 votos), a segunda fase é o próximo líder construindo e submetendo o bloco com base nesse certificado de quórum (QC).
Este compromisso em duas fases é necessário para garantir a segurança: uma vez que um número suficiente de nós honestos tenha bloqueado um bloco, o bloco em conflito não pode alcançar o quórum, e a próxima rodada de compromisso irá torná-lo permanente. Portanto, o cliente geralmente pode precisar esperar até que o próximo bloco ou a próxima rodada seja gerada para saber se a transação anterior foi finalmente confirmada.
O MonadBFT basicamente permite que as transações sejam consideradas suficientemente finais (podendo operar de forma segura) após apenas uma ronda de votação. Isso é conhecido como finalização especulativa.
Quando o líder propõe um Bloco e os validadores votam para formar o QC desse Bloco, este Bloco entra no estado de votação (já foi bloqueado pela maioria legal). No MonadBFT, assim que os validadores formam o QC, eles imediatamente executam as transações desse Bloco e podem até enviar uma confirmação preliminar ao cliente, indicando que o Bloco foi (especulativamente) aceito. É como dizer "temos a grande maioria das pessoas a concordar com este Bloco. A menos que ocorra uma situação muito inesperada, pode-se considerar que este Bloco está confirmado."
Esta confirmação instantânea é otimista. O bloco ainda não foi submetido no livro-razão. Isso acontecerá quando a próxima proposta surgir e confirmar isso (QC-on QC), mas em condições normais, nada irá revogar isso. A única situação que pode revogar um bloco de execução especulativa é quando o líder sofre um ataque equivalente (ou seja, propõe dois blocos diferentes na mesma altura para dispersar os votos).
Você pode ver a finalização especulativa como um excelente subproduto da resistência à forquilha de cauda. A resistência à forquilha de cauda garante que mesmo que o próximo líder falhe, a proposta atual não será descartada (graças à re-proposta e às regras do NEC). A única situação em que um bloco de execução especulativa é descartado é quando o proponente original sofre um ataque equivalente (um erro de dupla assinatura comprovadamente malicioso), e essa situação: 1) pode ser detectada por QC de conflito; 2) pode ser punida; 3) é extremamente rara.
Nos acordos anteriores, eles não garantem que o próximo líder irá reapresentar o bloco anterior, portanto, a forquilha final é possível, quebrando assim a hipótese de especulação.
Resposta otimista
Na maioria dos protocolos de consenso, há um período de espera embutido após cada rodada, como um período de amortecimento ou um tempo limite. Isso é para garantir que todas as mensagens tenham chegado antes de continuar a avançar. É um mecanismo de proteção destinado a lidar com as piores situações, como o colapso do líder ou a não envio de qualquer informação.
Esses prazos costumam ser excessivamente conservadores. Se a rede estiver funcionando normalmente e todos os validadores se comportarem corretamente, então a espera fixa se tornará um custo desnecessário. Os blocos poderiam ser concluídos mais rapidamente, mas o protocolo atrasou-se por precaução.
MonadBFT introduz uma resposta otimista, o que significa que o protocolo pode avançar imediatamente com base nas informações da rede, em vez de depender sempre de um temporizador fixo. O princípio de design aqui pode ser resumido como "se puder ser rápido, seja rápido; só seja paciente quando necessário".
O design do MonadBFT permite que, em condições normais e até mesmo durante a recuperação de falhas, não pause à espera de um tempo limite predefinido, a menos que seja necessário.
No caminho da felicidade (significa que temos um líder honesto): Não há atrasos embutidos nas propostas ou votações. Assim que for a vez do líder, ele propõe um bloco. Assim que o validador recebe uma proposta válida, ele vota imediatamente. Quando o líder (ou mais precisamente, o próximo líder, pois na linha de produção HotStuff, os votos são enviados ao próximo proponente) coleta 2f+1 votos, o QC é formado e pode ser propagado. Em um design de resposta otimista, isso desencadeia imediatamente a próxima fase.
Na prática, isso significa que se a latência da rede entre os nós for de 100 milissegundos, o consenso pode ser concluído em apenas algumas centenas de milissegundos para uma rodada (acrescido dos custos de cálculo e agregação).
Se não for necessário, não irá esperar, por exemplo, um "tempo de slot" de um segundo inteiro. Isso é diferente do modelo de slot e época adotado pela mainnet do Ethereum. No Ethereum, o intervalo de tempo para a produção de blocos é fixado em 12 segundos. Mesmo que todos estejam preparados com antecedência, o protocolo irá esperar.
O método MonadBFT elimina atrasos desnecessários. Ele mantém a estrutura HotStuff em pipeline, mas remove a exigência rígida de "esperar Δ segundos" que normalmente é necessária. Isso significa que pode superar sistemas com restrições de 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 o líder falha em propor um bloco, os outros nós só percebem isso após um tempo limite Δ. Por exemplo, se Δ for 1 segundo, esse tempo é basicamente desperdiçado. O tratamento do MonadBFT é diferente. Quando os validadores detectam que a proposta foi perdida, eles imediatamente transmitem uma mensagem de tempo limite (TC ou certificado de tempo limite). Assim que houver 2f+1 tempos limite, o próximo líder assume. A transição para a nova visão é desencadeada por provas baseadas na maioria, e não por um relógio.
Comparação com o consenso da família hotstuff
MonadBFT é construído sobre a base dos protocolos de consenso da série HotStuff, mas se destaca ao implementar uma combinação de uma série de características ideais. Os protocolos anteriores geralmente eram otimizados para certas dimensões, como taxa de transferência em pipeline ou comunicação linear, mas tinham que sacrificar outros aspectos. MonadBFT combina de forma única a complexidade de mensagens lineares, o envio em pipeline, uma forte resistência a forquilha de parte final, responsividade instantânea sem atraso fixo e um mecanismo de recuperação eficiente, enquanto ainda preserva a rápida determinação final e garantias de alta disponibilidade. A tabela abaixo resume a comparação entre MonadBFT e outros protocolos BFT com liderança rotativa nestas dimensões chave:
O que isso significa para os desenvolvedores e usuários?
Para os desenvolvedores, MonadBFT significa algumas coisas:
Modelo de determinação final mais simples: Com o MonadBFT, você pode considerar um bloco com QC (votação da maioria absoluta) como efetivamente finalizado, pois o protocolo irá finalizá-lo ou aplicar uma penalização. Os desenvolvedores podem operar com alta confiança de forma segura com 1 confirmação de bloco.
Melhorar a experiência do utilizador da aplicação: Se você está a construir uma aplicação de alto rendimento (como uma troca, jogos, etc.), as características de baixa latência e resistência a forquilha do MonadBFT resultarão numa experiência do utilizador mais fluída. Os utilizadores poderão praticamente ver as suas operações confirmadas de imediato, e não encontrarão frequentemente reorganizações ou retrocessos confusos. Assim, você poderá projetar uma aplicação com determinação final e atualizações rápidas.
Comportamento determinístico: As regras mais rígidas do MonadBFT, como requisitos de reproposta, reduzem a incerteza da inclusão de blocos. Há menos "casos extremos" em que os blocos são incluídos ou ignorados devido a fatores de tempo sutis, como se uma votação ou tempo limite atinge o líder primeiro. O MonadBFT substitui essa ambiguidade sensível ao tempo por regras claras e evidências verificáveis. Isso torna mais fácil inferir a correção do protocolo e testá-lo. Ele também fornece uma base clara para identificar nós defeituosos (por exemplo, se alguém não voltar a propor ou propor um bloco conflitante, você sabe que está violando o protocolo).
Espaço de escalabilidade: Se você é um desenvolvedor que se preocupa com escalabilidade, o MonadBFT oferece mais espaço para você antes de atingir um gargalo. Em comparação com protocolos secundários, você pode aumentar mais facilmente o tamanho do bloco ou o número de validadores. Além disso, funcionalidades como a propagação de blocos com codificação de apagamento significam que você pode enviar grandes quantidades de dados pela rede sem consumir excessivamente um único nó. Isso torna possível visar uma maior taxa de transferência, abrindo espaço de design para aplicações on-chain mais ambiciosas.
Para os usuários finais: Usuários comuns não entenderão nada do que estamos discutindo aqui, mas sentirão seu impacto. Com o MonadBFT como base da cadeia Monad, os usuários podem esperar todas as boas características a seguir, sem sacrificar a descentralização e resistindo à censura.
Confirmação mais rápida: transações (como enviar tokens, trocar ativos, cunhar NFTs, executar transações) serão rapidamente confirmadas.
Reduzir acidentes: a consistência do estado da cadeia é maior, pois coisas que pertencem essencialmente à reorganização, como forquilhas de cauda, foram eliminadas.
Justo e transparente: A melhoria do consenso implica indiretamente que a operação da cadeia é mais justa. Nenhum único validador pode facilmente revisar transações ou manipular a ordenação entre blocos.
Conclusão
Resumindo, o MonadBFT introduziu quatro inovações centrais com base no consenso estilo HotStuff em pipeline:
Resistência a forquilha de cauda: MonadBFT é o primeiro protocolo BFT em pipeline a eliminar ataques de forquilha de cauda. Ele alcança isso ao permitir que o próximo líder repropõe o bloco da última votação no caso de falha do líder anterior, ou apresenta um Certificado Sem Endosse (NEC), provando que o bloco carece de apoio. Isso garante que qualquer bloco que receba apoio de uma ampla maioria não seja descartado, protegendo assim as recompensas dos líderes honestos e prevenindo reestruturações maliciosas e extração de MEV entre blocos.
Finalidade da especulação de uma única rodada: Os validadores podem confirmar blocos após uma comunicação de uma única rodada (um líder propõe e vota), fornecendo garantias imediatas de inclusão aos clientes. Esta confirmação especulativa só será revertida em caso de ataque equivalente do líder (um comportamento que pode ser provado e punido), tornando-se assim uma suposição de segurança na prática.
Resposta otimista: O protocolo opera à velocidade da rede, sem atrasos inerentes. O líder avança imediatamente para o consenso após receber os votos necessários, e as mudanças de vista ocorrem imediatamente após observar a expiração do quórum, em vez de esperar um intervalo de tempo fixo. Este design de resposta otimista minimiza o tempo de espera e maximiza a taxa de transferência, enquanto ainda é capaz de lidar de forma robusta em casos de assíncrono e falhas.
Comunicação linear: No caminho feliz (ou seja, quando o líder é honesto), a complexidade das mensagens e das validações tem uma relação linear com o número de validadores. O MonadBFT mantém o eficiente padrão de comunicação do HotStuff, utilizando assinaturas agregadas e a simples transmissão do líder para os validadores, permitindo que o protocolo se expanda para centenas de validadores sem apresentar gargalos de desempenho.