Sempre que você envia uma transação de criptomoeda, recebe um pagamento ou interage com um contrato inteligente, uma rede de computadores que não se conhecem nem confiam uns nos outros precisa concordar que sua transação é válida e deve ser registrada permanentemente. Alguns desses computadores podem estar offline. Outros podem ser controlados por agentes mal-intencionados que enviam informações falsas deliberadamente. Mesmo assim, o blockchain precisa chegar à mesma conclusão correta em todos os nós honestos.
O mecanismo que torna isso possível é a Tolerância a Falhas Bizantinas (BFT). Trata-se de um dos conceitos mais importantes e menos compreendidos em sistemas distribuídos, que forma a base de segurança da tecnologia blockchain , das finanças descentralizadas, dos registros empresariais e da Internet das Coisas.
Este guia aborda a Tolerância a Falhas Bizantinas desde os princípios básicos até suas implementações modernas mais avançadas, incluindo sua comparação com a Prova de Trabalho (PoW) e a Prova de Participação (PoS), os vetores de ataque específicos contra os quais ela defende, os protocolos que se baseiam nela atualmente e os desafios que os pesquisadores ainda estão trabalhando para resolver.
O Problema dos Generais Bizantinos: Onde Tudo Começou
Para entender a Tolerância a Falhas Bizantinas, é preciso compreender o problema que ela foi projetada para resolver. O Problema dos Generais Bizantinos foi descrito formalmente pela primeira vez em 1982 pelos cientistas da computação Leslie Lamport, Robert Shostak e Marshall Pease em um artigo intitulado "The Byzantine Generals Problem", publicado na revista ACM Transactions on Programming Languages and Systems.
O problema é apresentado como uma analogia militar. Imagine várias divisões de um exército bizantino cercando uma cidade inimiga. Cada divisão é comandada por um general, e a comunicação entre elas se dá apenas por meio de mensageiros. Elas precisam concordar com um plano de ação comum: atacar ou recuar. Se atacarem juntas, vencem. Se recuarem juntas, sobrevivem. Mas se algumas atacarem enquanto outras recuarem, serão destruídas.
A complicação reside no fato de que alguns generais podem ser traidores. Um traidor poderia enviar mensagens diferentes para generais diferentes, ordenando a alguns "ataquem" e a outros "recuem", com o objetivo deliberado de impedir um acordo. Os generais leais não podem simplesmente ignorar as mensagens que suspeitam ser falsas, pois não conseguem identificar imediatamente quais generais são traidores.
O problema questiona: Que algoritmo os generais leais podem usar para garantir que todos cheguem à mesma decisão, mesmo quando uma parte deles são traidores que tentam ativamente causar discórdia?
Lamport, Shostak e Pease provaram que uma solução é possível se, e somente se, mais de dois terços dos generais forem leais. Dito de outra forma: um sistema de n nós pode tolerar, no máximo, f nós defeituosos ou maliciosos, desde que n seja pelo menos 3f + 1. Com menos de dois terços de participantes honestos, nenhum algoritmo pode garantir um acordo.
Esse resultado matemático tornou-se a base teórica para todos os algoritmos de consenso BFT que se seguiram.
Leia também: Como o hashing protege a tecnologia blockchain
O que é a tolerância a falhas bizantinas?
A tolerância a falhas bizantinas refere-se à propriedade de um sistema distribuído que lhe permite continuar a operar corretamente e alcançar consenso mesmo quando alguns dos seus nós falham de maneiras arbitrárias, incluindo o envio de mensagens conflitantes ou falsas, respostas inconsistentes a diferentes participantes ou comportamentos maliciosos para perturbar a rede.
O termo "Bizantino" denota especificamente a classe mais grave de falha: comportamento arbitrário, hostil e inconsistente. Isso é muito mais difícil de lidar do que uma simples falha de travamento (onde um nó para de responder completamente), porque um nó bizantino pode parecer se comportar corretamente às vezes, enquanto mina ativamente o consenso em outros momentos.
No contexto da tecnologia blockchain , a Tolerância a Falhas Bizantinas significa que a rede blockchain pode manter a integridade e continuar validando as transações corretamente, mesmo quando alguns validadores ou nós estão comprometidos, offline ou são deliberadamente maliciosos.
A regra estabelecida pelo artigo de Lamport se mantém válida: contanto que pelo menos dois terços dos nós da rede sejam honestos e operem corretamente, um sistema BFT alcançará o consenso adequado. No momento em que um único atacante controla mais de um terço dos nós, as garantias de segurança dos protocolos BFT clássicos começam a falhar.
Obtenha o cartão UPay Crypto
Experimente o melhor do pagamento on-line e transações criptográficas perfeitas.
RegistrarTolerância a falhas não bizantinas versus bizantinas: uma distinção crucial
Nem toda tolerância a falhas é igual. Compreender a diferença entre tolerância a falhas não bizantinas e bizantinas esclarece por que esta última é mais complexa e por que é tão importante para a blockchain.
A tolerância a falhas não bizantinas (de travamento) lida com o caso mais simples em que os nós podem falhar ao parar: eles travam, ficam offline ou se tornam inacessíveis. O sistema deve continuar mesmo que alguns nós estejam inativos. Isso é mais fácil de gerenciar porque um nó travado não envia mensagens e não causa confusão ativa. Sistemas como o Apache ZooKeeper e bancos de dados distribuídos mais antigos foram projetados com a tolerância a falhas de travamento em mente.
A Tolerância a Falhas Bizantinas lida com o caso mais complexo, em que nós com falha podem se comportar arbitrariamente, enviando mensagens incorretas, conflitantes ou estrategicamente enganosas para diferentes partes da rede. Um nó bizantino não se limita a ficar em silêncio; ele participa ativamente de maneiras projetadas para causar confusão ou impedir consenso. As redes blockchain estão expostas a esse problema mais complexo porque operam em ambientes abertos e sem permissão, onde qualquer pessoa pode executar um nó, incluindo adversários.
Especificamente no contexto da blockchain, as falhas bizantinas incluem: um minerador que inclui transações fraudulentas em um bloco proposto, um validador que assina blocos conflitantes na tentativa de realizar um fork, um nó que envia informações de ordem de transação diferentes para diferentes pares e nós que executam ataques de gasto duplo, transmitindo transações conflitantes simultaneamente para diferentes partes da rede.
Um sistema tolerante a falhas de travamento, mas não a falhas bizantinas, seria inadequado para uma blockchain pública, onde os nós são operados por partes desconhecidas e potencialmente adversárias.
Como a BFT é alcançada: os mecanismos principais
A tolerância a falhas bizantinas é alcançada por meio de combinações de três mecanismos principais que trabalham em conjunto para permitir que nós honestos cheguem a um acordo, apesar da presença de participantes adversários.
Redundância
Em vez de depender de um único nó para registrar ou validar uma transação, os sistemas BFT utilizam múltiplos nós redundantes. Contanto que mais de dois terços desses nós redundantes sejam honestos, o sistema consegue identificar e descartar a minoria de mensagens falsas ou conflitantes. A redundância é a base estrutural do BFT: é impossível alcançar a tolerância a falhas bizantinas sem usar mais nós do que o estritamente necessário para processar as transações.
Assinaturas criptográficas
Os protocolos BFT utilizam criptografia de chave pública para autenticar mensagens entre nós. Quando um nó envia uma mensagem (como um voto sobre a validade de um bloco proposto), ele assina essa mensagem com sua chave privada. Outros nós podem verificar a assinatura usando a chave pública do remetente, confirmando que a mensagem realmente veio do remetente declarado e não foi alterada durante a transmissão. Isso impede um dos ataques bizantinos mais perigosos: um nó malicioso se passando por outro nó, falsificando suas mensagens.
Protocolos de consenso estruturados
Os protocolos de consenso BFT definem regras precisas sobre como os nós propõem, votam e finalizam novos dados. Esses protocolos são especificamente projetados para que, mesmo que alguns nós enviem votos conflitantes, a maioria honesta possa chegar à mesma resposta final. A estrutura do protocolo elimina a ambiguidade: existe um processo definido para o que acontece quando os votos entram em conflito, quando um líder falha e quando os nós discordam sobre o estado atual.
As três propriedades que definem o consenso BFT
Todo protocolo de consenso BFT, independentemente de seu projeto específico, deve satisfazer três propriedades fundamentais:
Segurança significa que nenhum par de nós corretos (honestos) jamais decidirá sobre valores diferentes. Se um nó honesto confirmar uma transação como válida, nenhum outro nó honesto a confirmará como inválida. A segurança garante que o blockchain não se bifurque em históricos conflitantes entre participantes honestos.
A vivacidade significa que o sistema eventualmente progride. Se nós suficientes e corretos submeterem uma transação, essa transação será eventualmente confirmada. A rede não fica permanentemente travada. A vivacidade garante que os participantes honestos não sejam bloqueados indefinidamente, impedindo o processamento de suas transações.
Um acordo significa que, se um nó correto entregar uma transação, então todos os nós corretos entregarão a mesma transação. Todos os nós honestos veem os mesmos dados na mesma ordem.
Segurança e disponibilidade podem entrar em conflito. O famoso teorema CAP em sistemas distribuídos demonstra que nenhum sistema distribuído pode garantir simultaneamente consistência, disponibilidade e tolerância a partições. Os protocolos BFT fazem concessões deliberadas. A maioria prioriza a segurança em detrimento da disponibilidade: eles interrompem a execução em vez de confirmar um resultado potencialmente incorreto se muitos nós estiverem se comportando de maneira inadequada.
Leia também: O que é consenso em blockchain?
Tipos de algoritmos de tolerância a falhas bizantinas
A BFT evoluiu substancialmente desde o artigo de 1982. O campo agora inclui diversas famílias de protocolos distintas, cada uma com características de desempenho, pressupostos de confiança e contextos de implementação diferentes.
Tolerância prática a falhas bizantinas (PBFT)
A Tolerância a Falhas Bizantinas Prática (PbFT) foi introduzida por Barbara Liskov e Miguel Castro no MIT em 1999. Foi o primeiro algoritmo BFT suficientemente prático para implantação real em sistemas distribuídos, resolvendo o problema em redes assíncronas com baixa sobrecarga em comparação com trabalhos acadêmicos anteriores sobre BFT.
O PBFT funciona através de três fases de comunicação entre os nós:
Fase de pré-preparação: O nó primário (líder) recebe uma solicitação do cliente, atribui a ela um número de sequência e transmite uma mensagem de pré-preparação para todos os outros nós (chamados réplicas). Essa mensagem contém a solicitação, o número de sequência e o número da visualização atual.
Fase de preparação: Cada réplica que aceita a pré-preparação transmite uma mensagem de preparação para todas as outras réplicas. Uma réplica avança para a próxima fase somente quando recebe mensagens de preparação correspondentes de pelo menos 2f nós (onde f é o número máximo de nós com falha que o sistema tolera). Esse requisito de quórum impede que um líder com falha engane outras réplicas, fazendo com que aceitem números de sequência diferentes.
Fase de confirmação: Assim que um nó coleta mensagens de preparação suficientes que correspondam às suas necessidades, ele transmite uma mensagem de confirmação. Uma réplica executa a solicitação e responde ao cliente somente quando recebe mensagens de confirmação de pelo menos 2f + 1 nós. Esse quórum final garante que, mesmo que alguns nós que enviaram mensagens de confirmação falhem posteriormente, ainda existam nós confirmados em número suficiente para garantir a durabilidade do resultado.
Um cliente aceita um resultado quando recebe f + 1 respostas correspondentes, garantindo que pelo menos um nó honesto confirmou o resultado.
A complexidade de comunicação do PBFT é O(n²), o que significa que o número de mensagens cresce quadraticamente com o número de nós. Isso é administrável para dezenas ou algumas centenas de nós, mas torna-se proibitivo em grande escala. O PBFT também depende de um conjunto fixo e conhecido de validadores, o que o torna mais adequado para ambientes de blockchain permissionados ou de consórcio.
O PBFT pode tolerar até um terço (33%) de nós bizantinos. Este limite é matematicamente comprovado como sendo o máximo teórico para protocolos BFT clássicos.
O uso do consenso derivado do PBFT pelo Hyperledger Fabric é o exemplo empresarial mais proeminente. O Fabric utiliza um serviço de ordenação (anteriormente baseado em PBFT, agora baseado em Raft com um caminho de atualização para BFT através do SmartBFT) que proporciona alta taxa de transferência e baixa latência para aplicações empresariais. O Walmart utilizou o Hyperledger Fabric para rastrear itens alimentícios da fazenda à prateleira, demonstrando a implementação prática do BFT em um ambiente real de cadeia de suprimentos.
Acordo Bizantino Federado (FBA)
O Acordo Bizantino Federado (FBA) adota uma abordagem fundamentalmente diferente para o problema da confiança. Em vez de exigir que todos os validadores conheçam e concordem com o conjunto completo de validadores confiáveis, o FBA permite que cada nó defina sua própria "fatia de quórum", o subconjunto de outros nós em que ele confia pessoalmente.
O sistema atinge consenso global quando essas fatias de confiança individuais formam conjuntos sobrepostos. Se o nó A confia nos nós B e C, e o nó B confia nos nós A e D, a confiança sobreposta cria um quórum global implícito, mesmo que nenhuma autoridade central o tenha definido.
O FBA é o mecanismo de consenso subjacente à rede Stellar e, em forma modificada, à rede Ripple. A implementação do FBA na Stellar garante a finalidade das transações em três a cinco segundos e suporta milhares de transações por segundo, tornando-a prática para pagamentos internacionais. A MoneyGram e outros provedores de remessas utilizam a Stellar especificamente porque seu consenso FBA proporciona a finalidade rápida e confiável exigida pelos aplicativos de pagamento.
A abordagem FBA apresenta uma relação de compromisso diferente da PBFT: ela acomoda uma estrutura de confiança mais descentralizada, mas exige um projeto cuidadoso das fatias de quórum para garantir que a propriedade de consenso global seja mantida. Se as fatias de quórum forem mal definidas, partes da rede podem formar grupos de consenso desconectados que concordam com estados diferentes.
Coisa quente
O HotStuff é um protocolo de consenso BFT introduzido pelos pesquisadores Maofan Yin, Dahlia Malkhi, Michael Reiter, Guy Golan Gueta e Ittai Abraham em 2019. Ele se tornou extremamente influente como base para o protocolo LibraBFT do Facebook (usado no projeto blockchain Diem) e influenciou o design de diversos sistemas de consenso blockchain modernos.
A principal inovação do HotStuff é alcançar uma complexidade de comunicação linear, O(n), em vez da complexidade quadrática O(n²) do PBFT. Isso é possível graças a um design baseado em líder, no qual o líder coleta votos em assinaturas de limiar, agregando n votos individuais em uma única prova compacta. Isso significa que a sobrecarga de comunicação não aumenta exponencialmente à medida que o conjunto de validadores cresce.
O HotStuff utiliza uma estrutura de três fases (preparação, pré-confirmação e confirmação) que se assemelha conceitualmente às fases do PBFT, mas opera de forma mais eficiente por meio de pipeline: enquanto um bloco está sendo confirmado, o próximo bloco já está sendo proposto, melhorando drasticamente a taxa de transferência.
O HotStuff sacrifica uma latência ligeiramente maior (três viagens de ida e volta em vez de duas no PBFT) em troca de uma escalabilidade dramaticamente melhor. Para grandes conjuntos de validadores com centenas ou milhares de nós, essa troca é altamente vantajosa. O CometBFT do ecossistema Cosmos (anteriormente Tendermint Core) e o consenso usado no Aptos e no Sui são ambos baseados em designs da família HotStuff.
Hortelã-doce e Cometa BFT
O Tendermint é um algoritmo de consenso BFT projetado especificamente para uso em blockchain, introduzido por Jae Kwon em 2014. Ele separa a camada de consenso da camada de aplicação por meio da Interface de Blockchain de Aplicação (ABCI), permitindo que qualquer aplicação utilize o consenso Tendermint sem precisar construir sua própria infraestrutura de rede e consenso.
O Tendermint alcança consenso em rodadas. Em cada rodada, um proponente transmite um bloco. Os validadores votam em duas fases (pré-votação e pré-confirmação). Um bloco é confirmado quando pelo menos dois terços dos validadores enviam votos de pré-confirmação correspondentes. Se a rodada falhar (porque o proponente está com problemas ou a rede está muito lenta), uma nova rodada começa com um novo proponente.
O Tendermint oferece finalidade instantânea: uma vez que um bloco é confirmado, ele não pode ser revertido sem violar a premissa da maioria honesta de dois terços. Essa é uma vantagem significativa em relação a sistemas de finalidade probabilística, como a prova de trabalho (proof-of-work), em que uma transação só é considerada final após a adição de múltiplos blocos subsequentes.
O Tendermint processa milhares de transações por segundo com aproximadamente um segundo de latência. Em 2023, foi renomeado para CometBFT para refletir um modelo de governança comunitária mais abrangente. O Cosmos Hub e todas as blockchains baseadas no Cosmos SDK (totalizando mais de 100 blockchains ativas até 2025) utilizam o CometBFT como camada de consenso. Um exemplo notável em produção foi a paralisação da blockchain do Cosmos Hub v17.1, que não resultou de uma falha na prova de segurança central do CometBFT, mas sim de um bug de software no código de atualização do conjunto de validadores relacionado ao EndBlock, ilustrando como as garantias do BFT existem dentro de uma implementação completa, e não em isolamento teórico.
BFT em Prova de Participação: Casper e Ethereum
A transição do Ethereum para o Proof-of-Stake (PoS) por meio da fusão em setembro de 2022 introduziu o Casper FFG (Friendly Finality Gadget) combinado com a escolha do fork LMD-GHOST, formando juntos o protocolo de consenso Gasper. O Casper fornece finalidade no estilo BFT sobre um conjunto de validadores de PoS.
O Casper funciona como um mecanismo de finalidade integrado à produção de blocos. Os validadores votam nos pontos de verificação a cada 32 slots (aproximadamente 6.4 minutos). Quando dois terços do total de ETH em staking votam em um ponto de verificação, ele é considerado "justificado". Quando dois pontos de verificação consecutivos são justificados, o primeiro é "finalizado". Blocos finalizados não podem ser revertidos sem que o atacante queime pelo menos um terço de todo o ETH em staking, criando uma poderosa garantia econômica de BFT (Block Failed Token - Tolerância Zero a Blocos).
Esse mecanismo de penalização econômica é a adaptação do Ethereum ao BFT clássico: em vez de garantias puramente matemáticas, a finalidade é imposta pelo custo econômico do mau comportamento. Se um validador assinar blocos conflitantes, ele perde toda a sua participação (é "penalizado"). A ameaça de perder um capital substancial alinha o comportamento honesto com o interesse econômico próprio.
Tolerância a falhas bizantinas na prova de trabalho
A Prova de Trabalho (PoW) do Bitcoin alcança uma forma probabilística de Tolerância a Falhas Bizantinas por meio de um mecanismo diferente dos protocolos clássicos de Tolerância a Falhas Bizantinas. O white paper do Bitcoin, de Satoshi Nakamoto, publicado em 2008, apresentou a PoW como uma solução para o Problema dos Generais Bizantinos em um ambiente sem permissão, onde os participantes são desconhecidos e não podem ser pré-identificados.
No mecanismo de Prova de Trabalho (PoW) do Bitcoin, a tolerância a falhas bizantinas significa que, enquanto mineradores honestos controlarem mais de 50% do poder de hash total da rede, um atacante que controle menos de 50% não poderá reescrever o histórico de transações confirmadas. O custo de um ataque de 51% aumenta com a taxa de hash do Bitcoin e a dificuldade dos problemas de mineração.
Ao contrário dos protocolos BFT clássicos que fornecem finalidade absoluta após uma única rodada de votação, a finalidade do Bitcoin é probabilística: a probabilidade de uma transação ser revertida diminui exponencialmente a cada bloco adicional adicionado posteriormente. É por isso que confirmações de 6 blocos (aproximadamente uma hora) têm sido tradicionalmente usadas para grandes transações de Bitcoin.
A contrapartida é significativa: o PoW oferece BFT em um ambiente sem permissão, ao custo de um enorme consumo de energia, finalidade lenta (10 a 60 minutos) e a vulnerabilidade a ataques de 51% que os protocolos BFT clássicos nunca enfrentam abaixo de seu limite.
Comparação de protocolos BFT: uma visão geral direta
| Protocolo | Limiar de falha | Finalidade | Complexidade da mensagem | Mais Adequada Para |
| PBFT (Castro-Liskov) | 1/3 Bizantino | Instantâneo | O(n ao quadrado) | Pequenas redes com permissão |
| Coisa quente | 1/3 Bizantino | Instantâneo | O(n) linear | Conjuntos grandes de validadores |
| Hortelã-doce / Cometa BFT | 1/3 Bizantino | Instantâneo (~1s) | O (n) | Cadeias Cosmos, blockchains públicas |
| Contrato bizantino federado | Fatias de quórum sobrepostas | segundo 3-5 | Variável | Redes de pagamento (Stellar, Ripple) |
| Casper FFG (PoS Ethereum) | 1/3 do ETH em staking | A cada 6.4 minutos | O(n) com agregação BLS | blockchains PoS públicas |
| Bitcoin PoW | 50% de poder de hash | Probabilístico (6+ blocos) | O(1) transmissão | Redes sem permissão e sem confiança |
| Algorand BA | 1/3 Bizantino | ~ 4.5 segundos | Sublinear com VRF | Sem permissão, com finalidade rápida. |
Implementações práticas do BFT em 2025
Hyperledger Fabric e Blockchain Empresarial
O Hyperledger Fabric é a estrutura blockchain empresarial mais implantada em produção. Ele alimenta o sistema de rastreabilidade de alimentos do Walmart, as soluções de cadeia de suprimentos da IBM e centenas de aplicações financeiras e logísticas. O serviço de pedidos do Fabric passou por uma evolução significativa: após a migração do PBFT para o Raft (um consenso tolerante a falhas de travamento para implantações mais simples), o Fabric introduziu o SmartBFT como seu serviço de pedidos tolerante a falhas bizantinas para ambientes que exigem garantias completas de BFT. O SmartBFT segue o padrão de transmissão de três fases herdado do PBFT e oferece alta taxa de transferência com baixa latência, adequado para aplicações de nível empresarial.
Acordo Bizantino Federado da Stellar em Pagamentos Globais
A implementação FBA da Stellar processa milhões de transações diariamente, sendo utilizada por instituições financeiras como MoneyGram, Wirex e outras para pagamentos internacionais. O consenso da Stellar garante a liquidação final em três a cinco segundos, o que é ordens de magnitude mais rápido do que o sistema bancário correspondente tradicional (de um a cinco dias) e mais rápido do que a maioria das alternativas de blockchain. O modelo FBA permite que cada nó defina suas próprias relações de confiança, ao mesmo tempo que garante um acordo global, tornando o modelo de consenso da Stellar particularmente adequado para uma rede de pagamentos onde nem todos os participantes confiam plenamente uns nos outros, mas todos desejam uma liquidação confiável.
Protocolo de Acordo Bizantino de Algorand
Algorand emprega uma abordagem BFT única chamada Pure Proof of Stake, combinada com sorteio criptográfico. Em cada rodada de consenso, um comitê aleatório de validadores é selecionado usando uma Função Aleatória Verificável (VRF). Somente os membros selecionados do comitê sabem que foram escolhidos (e podem provar isso a outros), tornando ataques direcionados contra membros do comitê praticamente impossíveis, já que o atacante não sabe quem atacar antecipadamente.
O protocolo BA da Algorand atinge a finalidade em aproximadamente 4.5 segundos, com uma taxa de transferência superior a 1,000 transações por segundo em produção. Seu design oferece BFT em um ambiente sem permissão e sem o custo energético da prova de trabalho, uma combinação que o diferencia tanto do Bitcoin quanto dos sistemas BFT clássicos com permissão.
Ecossistema Cosmos e Cometa BFT
O ecossistema Cosmos em 2025 compreende mais de 100 blockchains soberanas, todas utilizando o CometBFT como camada de consenso. O protocolo de Comunicação Inter-Blockchain (IBC) depende da garantia de finalidade instantânea do CometBFT: as provas IBC são válidas somente porque o Cosmos Hub e suas blockchains contrapartes podem comprovar que uma transação foi realmente finalizada, e não apenas que provavelmente o será. Sem as fortes garantias de finalidade que o consenso BFT oferece, a comunicação entre blockchains desse tipo seria muito mais difícil de proteger. O ecossistema processa bilhões de dólares em transferências de valor entre blockchains diariamente, todas protegidas pelo consenso tolerante a falhas bizantinas do CometBFT.
BFT de Istambul de Klaytn
A Klaytn, implementada pela sul-coreana Kakao, utiliza o Istanbul BFT (IBFT), que processa mais de 4,000 transações por segundo com tempos de bloco de um segundo. O IBFT é uma variante do BFT compatível com a EVM, permitindo que a Klaytn mantenha a compatibilidade com as ferramentas do Ethereum, ao mesmo tempo que alcança um desempenho muito superior ao da camada base do Ethereum. Sua arquitetura híbrida público-privada permite que empresas executem sidechains permissionadas, enquanto a cadeia principal pública mantém as garantias descentralizadas do BFT.
Vetores de ataque contra os quais a BFT se defende
Entender contra o que o BFT protege esclarece seu valor e suas limitações.
Ataques de gasto duplo
Em um ataque de gasto duplo, um agente malicioso tenta gastar os mesmos fundos duas vezes, transmitindo duas transações conflitantes simultaneamente. O consenso BFT impede isso, exigindo que dois terços dos validadores concordem com uma única ordem de transação antes que qualquer transação seja finalizada. Uma vez que uma transação é confirmada em um sistema BFT, nenhuma transação concorrente pelos mesmos fundos pode ser confirmada sem violar o limite de dois terços.
Ataques de Eclipse
Em um ataque de eclipse, um atacante isola um nó específico cercando-o com pares maliciosos, controlando todas as informações que esse nó recebe. Um nó eclipsado com sucesso pode receber informações falsas sobre o estado da blockchain. Os protocolos BFT se defendem contra isso exigindo a concordância de uma supermaioria de todo o conjunto de validadores, e não apenas dos vizinhos imediatos de um nó. Mesmo que um nó seja eclipsado, a maioria honesta mais ampla rejeitará as transações que conflitem com o estado real da cadeia.
Ataques Sybil
Um ataque Sybil envolve um adversário criando múltiplas identidades de nós falsos para obter influência desproporcional sobre uma rede. Em sistemas BFT permissionados, os ataques Sybil são prevenidos pela exigência de que os validadores sejam formalmente registrados e autenticados. Em sistemas BFT de prova de participação (proof-of-stake), como o Ethereum, a resistência a ataques Sybil decorre do custo econômico do staking: a criação de múltiplos validadores exige o staking de valor real para cada um, tornando os ataques Sybil dispendiosos para serem executados em larga escala.
O Limiar de Ataque de 33%
Os protocolos BFT clássicos oferecem garantias de segurança apenas quando menos de um terço dos nós são bizantinos. Se um atacante controlar mais de um terço do conjunto de validadores (ou mais de um terço do valor em stake em sistemas PoS-BFT), a garantia de segurança do protocolo deixa de existir. Essa é a limitação fundamental do consenso BFT. Isso não significa que um atacante com 33% dos nós possa roubar fundos arbitrariamente, mas significa que ele pode potencialmente impedir a finalidade ou, no pior dos casos, fazer com que nós honestos confirmem estados conflitantes.
Por isso, o limite de 33% é uma consideração crítica para o modelo de segurança de qualquer sistema baseado em BFT. Protocolos como o Casper do Ethereum adicionam penalidades econômicas além do limite de BFT: mesmo que um atacante alcance um terço do ETH em staking, atacar com sucesso a finalidade exigiria que toda a sua participação fosse zerada, tornando o ataque economicamente devastador para o atacante.
Manipulação de mensagens e ataques de repetição
Sem assinaturas criptográficas , um nó bizantino poderia interceptar e modificar mensagens entre nós honestos, ou reproduzir mensagens válidas antigas para confundir o processo de consenso. Os protocolos BFT defendem-se contra a manipulação de mensagens exigindo que cada mensagem de consenso seja assinada com a chave privada do remetente. Números de sequência e identificadores de rodada incorporados nas mensagens impedem que mensagens válidas de uma rodada sejam reproduzidas em uma rodada posterior, causando confusão.
Obtenha o cartão UPay Crypto
Experimente o melhor do pagamento on-line e transações criptográficas perfeitas.
RegistrarObtenha o cartão UPay Crypto
Experimente o melhor do pagamento on-line e transações criptográficas perfeitas.
RegistrarVantagens da tolerância a falhas bizantinas em blockchain
Finalidade de transação determinística e instantânea
Talvez a vantagem mais importante do consenso BFT em relação aos sistemas de prova de trabalho seja a finalidade instantânea. No Bitcoin, uma transação nunca é matematicamente final; ela apenas se torna cada vez mais difícil de reverter à medida que mais blocos são adicionados. Em um sistema BFT, assim que o limite de dois terços é atingido na fase de commit, a transação é finalizada com certeza, de acordo com as premissas do protocolo. Não há necessidade de esperar por confirmações adicionais.
Isso é extremamente importante para aplicações financeiras. Redes de pagamento não podem funcionar de forma eficiente se cada transação puder ser revertida horas depois. Aplicações de finanças descentralizadas exigem finalidade confiável para liquidações, empréstimos e liquidação de derivativos. A comunicação entre blockchains por meio de protocolos como o IBC exige que uma blockchain prove à outra que uma transação específica é realmente final.
Eficiência energética
O consenso BFT clássico não exige o enorme trabalho computacional necessário para a prova de trabalho do Bitcoin. Os validadores votam usando assinaturas digitais, e não resolvendo quebra-cabeças computacionalmente intensivos. Isso torna o BFT dramaticamente mais eficiente em termos de energia. A transição do Ethereum para PoS-BFT reduziu seu consumo de energia em aproximadamente 99.95%, uma redução possível justamente por substituir a prova de trabalho pela votação de validadores no estilo BFT.
Resiliência a falhas de rede e nós maliciosos
Um protocolo BFT bem implementado continua operando corretamente enquanto dois terços dos nós permanecerem honestos e conectados. Ele lida com falhas de conexão, partições de rede (temporárias), nós bizantinos e combinações desses fatores simultaneamente. Essa resiliência é exatamente o que as redes blockchain públicas precisam: elas não podem saber antecipadamente quais nós falharão ou se comportarão de forma maliciosa, portanto, o protocolo de consenso deve lidar com falhas arbitrárias de maneira adequada.
Alto desempenho para sistemas autorizados
Os protocolos BFT em ambientes permissionados como o Hyperledger Fabric podem atingir uma taxa de transferência de transações muito alta. Como o conjunto de validadores é fixo e conhecido, a sobrecarga de comunicação é previsível e otimizável. Implantações corporativas rotineiramente alcançam milhares de transações por segundo com finalidade inferior a um segundo, um desempenho impossível com prova de trabalho e desafiador até mesmo para muitos sistemas de prova de participação.
Segurança contra falhas bizantinas e ataques coordenados
Os mecanismos BFT oferecem proteção robusta contra ataques bizantinos coordenados. Um grupo de nós maliciosos em conluio, representando menos de um terço do conjunto de validadores, não pode interromper o consenso, independentemente de quão estrategicamente se comporte. Eles não podem impedir que nós honestos cheguem a um acordo, não podem injetar transações falsas no histórico acordado e não podem fazer com que nós honestos assumam estados conflitantes. Essa forte garantia de segurança é comprovada matematicamente, e não apenas observada empiricamente.
Desafios e limitações da tolerância a falhas bizantinas
Restrições de escalabilidade
O principal desafio dos algoritmos BFT clássicos é que a complexidade de comunicação aumenta com o número de validadores. A complexidade de mensagens O(n²) do PBFT significa que adicionar mais validadores rapidamente se torna impraticável. Uma rede com 100 validadores PBFT requer até 10,000 mensagens por rodada de consenso. Com 1,000 validadores, esse número sobe para 1,000,000 de mensagens.
O HotStuff e seus derivados resolveram esse problema drasticamente, reduzindo a complexidade para O(n) linear por meio da agregação de assinaturas por limiar. Mas mesmo a complexidade linear tem limites práticos. A maioria dos blockchains públicos atuais baseados em BFT mantém conjuntos de validadores na casa das centenas a alguns milhares, em vez das dezenas de milhares que a rede de mineração do Bitcoin inclui.
Essa limitação de escalabilidade explica por que o consenso BFT é comum em blockchains permissionadas e redes de prova de participação (proof-of-stake) com conjuntos de validadores limitados, enquanto a prova de trabalho (proof-of-work) sem permissão continua sendo o mecanismo para redes que priorizam a participação irrestrita.
Dependência de um conjunto de validadores conhecido
A maioria dos protocolos BFT exige um conjunto definido e autenticado de validadores. Isso funciona bem em ambientes com permissão e em redes de prova de participação (proof-of-stake), onde os validadores depositam capital para garantir sua posição. É muito mais difícil em ambientes totalmente sem permissão, onde qualquer pessoa pode participar sem registro. A prova de trabalho (proof-of-work) do Bitcoin resolveu a versão sem permissão do Problema dos Generais Bizantinos justamente porque a PoW não exige saber quem são os participantes com antecedência.
Sobrecarga de desempenho
A obtenção de tolerância a falhas bizantinas exige uma comunicação significativamente maior entre os nós do que em sistemas tolerantes a falhas não bizantinas. A votação multifásica necessária em protocolos do tipo PBFT, a necessidade de coletar e verificar um grande número de mensagens criptograficamente assinadas e a sobrecarga de coordenação dos protocolos de mudança de visão (lidar com líderes falhos) aumentam a latência e o custo computacional. Para aplicações que exigem milhares de transações por segundo com latência muito baixa, essas sobrecargas requerem um projeto cuidadoso.
Complexidade da implementação correta
As provas matemáticas que fundamentam os algoritmos BFT são exatas: o protocolo é seguro e ativo se implementado precisamente como especificado. Mas o software raramente é exatamente como especificado. Implementações reais contêm bugs de concorrência, casos extremos no tratamento de rede, vulnerabilidades de temporização de mensagens e erros de implementação criptográfica que podem violar as garantias do protocolo na prática, mesmo quando o projeto teórico é sólido. A interrupção da cadeia do Cosmos Hub v17.1 ilustra isso: a garantia de segurança central do BFT foi mantida, mas um erro de software no código circundante causou uma interrupção na produção. A implementação correta do BFT exige extremo rigor em toda a pilha de implementação, não apenas na lógica da rodada de consenso.
Vulnerabilidade no limiar de 33%
O requisito de maioria honesta de 33% é tanto a força do BFT quanto seu limite intransponível. Enquanto essa premissa for válida, o sistema é seguro. Mas se um atacante obtiver o controle de um terço ou mais do conjunto de validadores (ou um terço do valor em staking em sistemas PoS-BFT), as garantias de segurança são comprometidas. Na prática, isso exige recursos enormes para redes estabelecidas, mas redes menores com menor valor total em staking são mais vulneráveis a esse ataque.
O futuro da tolerância a falhas bizantinas em blockchain
BFT pós-quântica
Os protocolos BFT atuais dependem de esquemas de assinatura criptográfica vulneráveis a computadores quânticos. Um computador quântico suficientemente poderoso poderia quebrar a criptografia de chave pública que os protocolos BFT usam para autenticar os votos dos validadores. A pesquisa em BFT pós-quântico está explorando ativamente esquemas de assinatura resistentes a ataques quânticos, incluindo criptografia baseada em reticulados e em hashes. A Trezor Safe 7, uma carteira de hardware, já implementa criptografia pós-quântica padronizada pelo NIST para verificação de firmware, indicando que o ecossistema criptográfico mais amplo está caminhando em direção à resistência quântica. Os protocolos BFT precisarão seguir o mesmo caminho à medida que a computação quântica avança.
Protocolos BFT assíncronos
O PBFT clássico e a maioria de seus derivados dependem de suposições de sincronia parcial: assumem que os atrasos nas mensagens são eventualmente limitados, mesmo que o limite seja desconhecido. Sob condições completamente assíncronas (onde os atrasos nas mensagens podem ser arbitrariamente longos), o teorema da impossibilidade FLP prova que o consenso determinístico é impossível. No entanto, protocolos BFT assíncronos randomizados que utilizam funções aleatórias verificáveis podem alcançar consenso probabilístico mesmo sob assincronia completa. HoneyBadgerBFT e Dumbo são exemplos de protocolos BFT assíncronos projetados para funcionar de forma confiável mesmo quando as condições da rede estão severamente degradadas.
Escalabilidade por meio de fragmentação e camada 2
Uma abordagem promissora para superar o limite de escalabilidade do BFT é executar múltiplas instâncias do BFT em paralelo por meio de sharding, onde a rede é dividida em subconjuntos (shards) que executam seu próprio consenso BFT em uma parte das transações. O roadmap do Ethereum inclui sharding juntamente com a finalidade no estilo BFT. A arquitetura app-chain do Cosmos é outra forma de escalabilidade horizontal: cada aplicação executa sua própria cadeia CometBFT, distribuindo a carga de consenso. Soluções de camada 2, como rollups, adicionam outra dimensão ao agrupar transações fora da cadeia principal e usar cadeias seguras por BFT para a liquidação final.
BFT na Internet das Coisas
As redes IoT representam um caso de uso convincente para o consenso BFT. Bilhões de dispositivos IoT precisam coordenar e compartilhar dados com segurança em redes distribuídas, onde dispositivos individuais podem ser fisicamente comprometidos, ficar sem energia ou serem manipulados deliberadamente. Pesquisas de 2025 mostram que algoritmos baseados em BFT fornecem a baixa latência exigida por aplicações IoT, embora seu alto custo computacional e vulnerabilidade a ataques de 33% tornem necessárias arquiteturas de rede com permissão para implantações de IoT. A Internet das Coisas representa uma das áreas de maior crescimento para pesquisa e implementação de BFT.
BFT em Finanças Descentralizadas
Os aplicativos de finanças descentralizadas (DeFi) , que acumularam mais de US$ 56.3 bilhões em valor total bloqueado até 2025, dependem fundamentalmente do consenso BFT para a confiabilidade de suas operações. Liquidações, feeds de preços de oráculos, posições de empréstimo e liquidações de derivativos exigem finalidade rápida e confiável. Todos os principais protocolos DeFi operam em blockchains com consenso do tipo BFT: Ethereum com Casper, Cosmos Chain com CometBFT e Stellar com FBA. À medida que os aplicativos DeFi se tornam mais sofisticados e lidam com mais valor, a demanda por garantias BFT se torna ainda mais crítica.
Interoperabilidade entre sistemas BFT
Obtenha o cartão UPay Crypto
Experimente o melhor do pagamento on-line e transações criptográficas perfeitas.
RegistrarO futuro do blockchain é cada vez mais multichain. Ativos e mensagens transitam entre as redes Ethereum, Cosmos, Stellar, Hyperledger e outras. A interoperabilidade entre blockchains exige que cada blockchain verifique as provas de finalidade das transações em outras blockchains. A finalidade instantânea do BFT simplifica drasticamente esse processo: uma prova BFT finalizada é compacta e verificável, diferentemente da finalidade probabilística da prova de trabalho (PoW) , que exige a espera por diversas confirmações antes que qualquer operação entre blockchains seja segura. O protocolo IBC no ecossistema Cosmos e os projetos de pontes entre blockchains no ecossistema mais amplo dependem da finalidade do BFT para funcionar com segurança. A pesquisa em interoperabilidade é uma das fronteiras mais ativas no projeto de protocolos BFT.
Perguntas frequentes
O que é a tolerância a falhas bizantinas em termos simples?
A tolerância a falhas bizantinas é uma propriedade de sistemas distribuídos que permite que eles continuem funcionando corretamente mesmo quando alguns participantes são desonestos, apresentam falhas ou tentam ativamente interromper o sistema. Em blockchain, isso significa que a rede continua validando as transações corretamente mesmo que alguns nós enviem informações falsas ou tentem manipular o processo. A regra fundamental é que, contanto que mais de dois terços dos nós sejam honestos, o sistema chega à conclusão correta.
Por que é chamada de tolerância a falhas “bizantina”?
O nome vem do Problema dos Generais Bizantinos, um experimento mental publicado pelos cientistas da computação Lamport, Shostak e Pease em 1982. Na analogia, os generais bizantinos precisam concordar com um plano de batalha, mesmo que alguns deles sejam traidores enviando mensagens falsas. "Bizantino" se refere ao pior tipo de falha: comportamento arbitrário e hostil, não apenas uma falha ou silêncio.
Quantos nós defeituosos um sistema BFT pode tolerar?
Os protocolos BFT clássicos, incluindo PBFT, Tendermint e HotStuff, toleram, no máximo, um terço dos nós sendo bizantinos. Um sistema com n nós pode lidar com f nós bizantinos, desde que n seja pelo menos 3f + 1. Se mais de um terço dos nós forem defeituosos ou maliciosos, as garantias de segurança desses protocolos são comprometidas. Este é matematicamente comprovado como o máximo teórico para BFT clássico sob as premissas padrão de rede.
Qual a diferença entre PBFT e HotStuff?
Tanto o PBFT quanto o HotStuff são protocolos BFT baseados em líder que toleram até um terço de nós bizantinos e fornecem finalidade instantânea. A principal diferença reside na complexidade da comunicação. O PBFT requer O(n²) mensagens por rodada de consenso, limitando seu uso a conjuntos de validadores menores. O HotStuff alcança comunicação linear O(n) agregando votos em assinaturas de limiar, o que o torna viável para conjuntos de validadores muito maiores. O HotStuff utiliza três viagens de ida e volta em vez das duas do PBFT, um pequeno aumento na latência que é mais do que compensado pela melhoria na escalabilidade.
O Ethereum utiliza tolerância a falhas bizantinas?
Sim. O consenso de prova de participação (proof-of-stake) do Ethereum usa o Casper FFG como mecanismo de finalização, que é um mecanismo de votação no estilo BFT (Broadcast Forwarding). Os validadores votam nos blocos de checkpoint e, quando dois terços dos ETH em staking votam em um checkpoint, ele é finalizado. O Ethereum adiciona segurança econômica além do limite clássico do BFT: validadores que agem de forma bizantina são penalizados (perdem seus ETH em staking), tornando os ataques financeiramente devastadores, além de matematicamente difíceis.
