---
title: "Tolerância a falhas bizantinas: segurança, vivacidade e quóruns"
description: "A tolerância a falhas bizantinas descreve quando um protocolo distribuído permanece seguro e ativo diante de falhas arbitrárias. Protocolo, modelo de rede, limite de falhas, quórum, pesos, finalidade e recuperação devem ser avaliados em conjunto."
image: "https://wiki.fcontext.com/og.png"
---
> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Tolerância a falhas bizantinas: segurança, vivacidade e quóruns
> Material educativo para análise de protocolos. O rótulo BFT ou um limiar de quórum, isoladamente, não comprova segurança, vivacidade, execução correta, descentralização, finalidade nem proteção dos ativos.
## Resposta direta
Tolerância a falhas bizantinas (BFT) é uma propriedade de um protocolo distribuído específico sob modelos específicos de falha e rede: ele mantém as garantias declaradas mesmo que participantes parem, retenham mensagens, enviem mensagens conflitantes a pares diferentes ou se comportem de modo arbitrário. BFT não é um único algoritmo nem significa que todos os serviços permaneçam disponíveis durante qualquer partição.
As garantias precisam ser separadas. `safety` (segurança) impede participantes honestos de decidir valores conflitantes; `liveness` (vivacidade) permite que entradas elegíveis acabem levando a uma decisão; `validity` (validade) limita quais valores podem ser decididos. Um protocolo pode parar para preservar segurança quando faltam comunicação ou poder de voto honesto. Consenso correto também não prova a correção do código da aplicação, das regras de validade, das pontes, das chaves ou da governança.
Em uma classe comum de protocolos BFT autenticados e parcialmente síncronos, `n=3f+1` réplicas toleram no máximo `f` réplicas bizantinas e um certificado de confirmação usa `q=2f+1` votos. As expressões “menos de um terço falho” e “quórum acima de dois terços” vêm desse modelo. Protocolos síncronos, assíncronos aleatorizados, tolerantes a falhas por parada, cadeias de prova de trabalho e outras construções BFT podem ter premissas e limites diferentes.
Em sistemas ponderados por participação, o limiar se refere ao poder de voto definido pelo protocolo, não necessariamente à quantidade de validadores, endereços, pessoas ou operadores independentes. Antes de aplicar uma fração, registre versão exata, fotografia dos pesos, tipo de decisão, premissa de rede, comparação do quórum (`>` ou `>=`) e comportamento de falha.
## Como funciona
1. **Defina a decisão.** Identifique se os nós ordenam transações, confirmam bloco, finalizam ponto de controle, elegem líder, aceitam transição de estado ou escolhem bifurcação. Essas decisões não são equivalentes.
2. **Declare os modelos de sistema e adversário.** Registre membros, autenticação, mudanças de permissão, pesos, corrupção adaptativa, chaves comprometidas, equivocação, paradas, perda de mensagens, censura, negação de serviço e possíveis falhas correlacionadas.
3. **Declare o modelo de rede.** Diferencie sincronia, sincronia parcial e assincronia. Na sincronia parcial, identifique o que só é garantido depois de um tempo global de estabilização desconhecido e como os tempos-limite se ajustam.
4. **Derive a regra de quórum.** Use o limiar e as regras exatas de bloqueio ou voto. No caso clássico `n=3f+1`, dois quóruns `2f+1` se cruzam em pelo menos `f+1` réplicas; se no máximo `f` forem bizantinas, a interseção contém uma honesta.
5. **Acompanhe todas as fases e certificados.** Verifique proposta, voto, bloqueio, mudança de visão ou rodada, confirmação, escolha de bifurcação e recuperação. Uma supermaioria assinada só tem valor se altura, rodada, valor, pai, domínio, época de membros e certificado anterior forem validados.
6. **Separe evidências de segurança e vivacidade.** Prove quais decisões conflitantes são excluídas em todos os momentos relevantes e depois teste se o avanço volta quando as premissas de comunicação e participação honesta passam a valer. Tempo-limite é ferramenta de agendamento, não prova de malícia.
7. **Verifique implementação e operação.** Compare diversidade de clientes, custódia de chaves, contingência de assinantes, proteção contra repetição, sincronização de estado, tratamento de provas, mudanças de membros, monitoramento, política de confirmação e recuperação com o modelo provado.
O resultado FLP diz que um protocolo de consenso determinístico não consegue garantir término em um modelo totalmente assíncrono mesmo com uma possível falha por parada. Não diz que segurança é impossível nem que consenso distribuído nunca funciona. Sincronia parcial, aleatoriedade, detectores de falha, premissas econômicas ou garantias mais fracas alteram, de modos diferentes, as condições específicas da impossibilidade.
## Exemplos calculados
### 1. Quatro réplicas de mesmo peso
Considere `n=4`, `f=1` e `q=3`. Dois conjuntos de três votos se cruzam em pelo menos `3+3-4=2` réplicas. Com no máximo uma réplica bizantina, pelo menos uma da interseção é honesta. Se as regras honestas proíbem votos em valores conflitantes no histórico relevante de altura e rodada, dois certificados conflitantes não podem se formar.
Se duas réplicas ficam offline, restam apenas `2` votos e nenhum certificado `q=3` é formado. É falha de vivacidade, não automaticamente de segurança: um protocolo seguro espera em vez de reduzir localmente o limiar.
### 2. Sete réplicas de mesmo peso
Considere `n=7`, `f=2` e `q=5`. Dois quóruns se cruzam em pelo menos `5+5-7=3=f+1` réplicas. Como no máximo `2` são bizantinas, há uma honesta na interseção. Duas bizantinas não criam sozinhas um certificado de cinco votos, mas três ausentes ou retendo votos deixam só `4` e podem impedir avanço.
A aritmética do limiar é necessária, mas insuficiente. Se implementações honestas aceitam votos de outra altura, reutilizam membros, violam um bloqueio ou assinam com chaves comprometidas, as premissas da prova deixam de representar a implantação.
### 3. Poder de voto ponderado
Suponha pesos `40`, `30`, `20` e `10`, total `100`, e certificado exigindo estritamente mais de `2/3`, implementado aqui como pelo menos `67`. A coalizão `40+30=70` certifica; `30+20+10=60` não, embora reúna três de quatro validadores. Se o validador de peso `40` ficar offline, restam `60` e a finalidade para.
Dois conjuntos de pelo menos `67` se cruzam em pelo menos `67+67-100=34`. Portanto, certificados conflitantes implicam que ao menos `34` de peso participou dos dois ou outra premissa falhou. Em alguns protocolos, pouco mais de um terço equivocando pode violar segurança; “dois terços para atacar” não é mínimo universal.
### 4. Sincronia parcial e tempos-limite
Suponha tempos de rodada de `1 s`, `2 s`, `4 s` e `8 s`. Antes do instante desconhecido de estabilização, mensagens podem chegar após cada prazo, mudando rodadas sem decisão. Se depois o atraso ficar abaixo de `3 s`, uma rodada de `4 s` ou posterior pode dar tempo para proponente honesto e quórum avançarem, sujeitos às demais premissas.
Os números ilustram avanço eventual, não uma fórmula universal. Prazos curtos causam mudanças desnecessárias; longos aumentam a recuperação. Segurança não pode depender de adivinhar o limite de atraso antes da estabilização.
## Riscos e falhas de revisão
### Modelo e prova
- Dizer “BFT” sem nomear protocolo, versão, decisão, modelo de falha, rede, membros e limiar.
- Aplicar `n=3f+1` ou um terço a todo registro distribuído, mesmo com provas sob outras premissas.
- Confundir segurança, vivacidade, validade, disponibilidade, consistência, finalidade, escolha de bifurcação e correção de transações.
- Dizer que FLP torna consenso impossível sem manter suas condições de determinismo, assincronia total e término garantido.
- Contar nós ou endereços quando o protocolo conta participação, delegação, comitês, épocas ou outro recurso.
- Arredondar “dois terços” de forma ambígua ou ignorar `>`, `>=`, pesos inteiros e fotografia do denominador.
- Conferir tamanho do quórum sem interseção, bloqueios, certificados, mudanças de visão, reconfiguração e transferência de estado.
- Presumir que uma prova cobre corrupção adaptativa, roubo de chaves, falhas correlacionadas, negação de serviço ou histórico remoto.
### Implementação e operação
- Aceitar assinaturas sem vincular cadeia, domínio, altura, rodada, valor, pai, época de membros e tipo de mensagem.
- Repetir votos ou certificados antigos entre rodadas, alturas, bifurcações, redes, atualizações ou mudanças de validadores.
- Permitir assinatura dupla, regressão de bloqueio, contingência insegura ou duas réplicas ativas com a mesma identidade.
- Tratar expiração do prazo como prova de malícia e decidir sobre segurança só com relógios locais.
- Ignorar falhas correlacionadas por cliente, nuvem, região, rede, hardware, gestão de chaves ou operador comum.
- Presumir que penalização impede falhas, recupera vivacidade, reverte ação finalizada ou indeniza todos.
- Testar apenas o fluxo normal e não partições, atrasos, reordenação, equivocação, falha do proponente, reinícios e mudança de membros.
### Aplicação e governança
- Tratar valor confirmado como estado válido sem execução determinística e validação de transição.
- Creditar depósitos, emitir ativos em ponte ou liquidar operações antes da condição exata de finalidade exigida.
- Igualar finalidade do protocolo a irreversibilidade social após chave comprometida, falha de software ou intervenção de governança.
- Ignorar censura e atraso de inclusão porque blocos de outros usuários continuam finalizando.
- Inferir descentralização, segurança de ativos, valor do token ou força jurídica do rótulo BFT ou da contagem anunciada de validadores.
## Equívocos comuns
- **BFT significa que a rede nunca para.** Muitos protocolos sacrificam deliberadamente vivacidade durante falhas excessivas ou partições para preservar segurança.
- **Mais de 51% de participantes honestos sempre basta.** O limiar depende do protocolo; BFT parcialmente síncrono clássico costuma exigir mais de dois terços do poder relevante para avançar.
- **O atacante sempre precisa de dois terços para quebrar segurança.** Dois terços podem certificar sozinhos, mas dois certificados conflitantes podem revelar pouco mais de um terço equivocando.
- **Mais endereços de validadores melhoram automaticamente a tolerância.** Propriedade comum, delegação, clientes, infraestrutura, chaves e domínios de falha determinam independência.
- **A penalização é a prova BFT.** É resposta econômica de alguns sistemas PoS; segurança vem das regras e premissas, e sanções não desfazem consequências externas.
## Tópicos relacionados
- [Problema dos generais bizantinos](/pt-br/crypto/byzantine-generals-problem/)
- [Mecanismo de consenso](/pt-br/crypto/consensus-mechanism/)
- [Finalidade](/pt-br/crypto/finality/)
- [Prova de participação](/pt-br/crypto/proof-of-stake/)
- [Validador](/pt-br/crypto/validator/)
## Fontes
- [The Byzantine Generals Problem](https://lamport.azurewebsites.net/pubs/byz.pdf) - ACM Transactions on Programming Languages and Systems (acesso em: 2026-08-18)
- [Impossibility of Distributed Consensus with One Faulty Process](https://groups.csail.mit.edu/tds/papers/Lynch/jacm85.pdf) - Journal of the ACM (acesso em: 2026-08-18)
- [Consensus in the Presence of Partial Synchrony](https://groups.csail.mit.edu/tds/papers/Lynch/jacm88.pdf) - Journal of the ACM (acesso em: 2026-08-18)
- [Practical Byzantine Fault Tolerance](https://pmg.csail.mit.edu/papers/osdi99.pdf) - USENIX OSDI (acesso em: 2026-08-18)
- [CometBFT Consensus Algorithm](https://docs.cometbft.com/v0.38/spec/consensus/consensus) - CometBFT (acesso em: 2026-08-18)
- [HotStuff: BFT Consensus with Linearity and Responsiveness](https://arxiv.org/abs/1803.05069) - arXiv (acesso em: 2026-08-18)
- [Gasper](https://ethereum.org/developers/docs/consensus-mechanisms/pos/gasper/) - Ethereum.org (acesso em: 2026-08-18)
- [Blockchain Technology Overview](https://doi.org/10.6028/NIST.IR.8202) - NIST (acesso em: 2026-08-18)
Source: https://wiki.fcontext.com/pt-br/crypto/byzantine-fault-tolerance/index.mdx