Ir para o conteúdo
Financial Context Wiki

Tolerância a falhas bizantinas: segurança, vivacidade e quóruns

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.

Atualizado

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.

Abaixo do limite
25%
Participação adversária
25%
Margem até o limite
8,4%

Os resultados são aproximações educacionais. Eles excluem regras de local, impostos, latência, comportamento do oráculo e outros parâmetros específicos do protocolo, a menos que sejam mostrados.

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

Fontes

Navegação

Pesquisar na wiki...