Ir para o conteúdo
Financial Context Wiki

Mecanismos de consenso: validade, escolha de fork e finalidade

Um mecanismo de consenso coordena réplicas em históricos compatíveis sob premissas explícitas de falha e rede. Analise separadamente decisão, participantes e pesos, validade, proposta, escolha de fork, finalidade, segurança, vivacidade e implantação.

Atualizado

Material educativo para análise de protocolos. O rótulo de consenso, isoladamente, não comprova segurança, vivacidade, implementação correta, descentralização, finalidade, ordenação justa nem proteção dos ativos em uma rede implantada.

Resposta direta

Um mecanismo de consenso é o protocolo pelo qual réplicas sem falha convergem em decisões compatíveis sobre um log ordenado ou estado apesar de atraso, concorrência e falhas abrangidas pelo modelo. Em uma blockchain, o mecanismo completo pode incluir seleção de proponente, validação de blocos e transições de estado, votos ou provas, escolha de fork, compromisso ou finalidade, recuperação e regras de participação. Não é apenas “muitos computadores guardando o mesmo arquivo”, um limiar de votos, mineração, staking ou tabela de incentivos.

Três propriedades precisam ser declaradas separadamente. safety (segurança) impede decisões incompatíveis entre participantes sem falha; liveness (vivacidade) afirma que trabalho válido pode progredir sob condições especificadas; validity (validade) limita o que pode ser decidido. Um protocolo pode parar preservando segurança ou continuar sob premissas que permitem reorganização posterior. A palavra “consenso” não identifica sozinha qual garantia vale, quando vale nem em qual evidência um cliente deve confiar.

Validade de transação e seleção canônica são diferentes. Um nó completo rejeita de forma independente uma transição que viole as regras atuais. Se duas transações individualmente válidas gastam a mesma entrada, ordenação ou escolha de fork decide qual entra no histórico canônico; maioria de recursos não torna ambas válidas. Da mesma forma, concordar sobre bytes não prova a veracidade de um fato de oráculo, alegação de ponte, cálculo de aplicação ou afirmação jurídica.

Proof of Work e Proof of Stake geralmente fornecem resistência a Sybil, influência de proposta ou peso de voto responsabilizável, mas seus nomes não especificam um protocolo completo. Bitcoin combina prova de trabalho com validação e seleção por trabalho acumulado. Gasper da Ethereum combina atestações ponderadas por stake, escolha LMD-GHOST e finalidade de checkpoints Casper FFG. Um BFT por rodadas como CometBFT tem outras mensagens, limiares, premissas temporais e finalidade. Seus percentuais não são intercambiáveis.

Como analisar

  1. Nomeie a decisão e o escopo. Especifique se as réplicas decidem um valor, log ordenado, bloco por altura, checkpoint ou estado de aplicação; identifique cadeia, rede, camada, versão e ponto inicial confiável.
  2. Defina participantes e influência. Separe proponentes, votantes, validadores completos, clientes leves e observadores. Registre entrada e saída de identidades, se a influência segue hash, stake, membros iguais ou outro peso, e como identidades duplicadas baratas são impedidas.
  3. Separe as etapas. Documente validade de transação e estado, construção e disseminação de proposta, voto ou prova, escolha de fork, compromisso, finalidade e recuperação. Um bloco válido pode perder a escolha e uma cabeça canônica pode ainda não estar finalizada.
  4. Declare o modelo do sistema. Defina canais autenticados, sincronia ou sincronia parcial, atraso e timeout, falhas por parada e bizantinas, equivocação, omissão, corrupção adaptativa, comprometimento de chave, partições e máximo número ou peso defeituoso f.
  5. Rastreie uma decisão. Siga domínios de mensagens, alturas, rodadas, pais, travas, certificados e estado local da proposta à decisão. Mostre o tratamento de mensagem atrasada, proponente equívoco, timeout de rodada ou duas ramificações válidas.
  6. Verifique segurança e vivacidade separadamente. Derive interseção de quórum, crescimento de cadeia ou outras condições usando o conjunto e o snapshot de pesos exatos. Depois teste se restam conectividade e participação honestas suficientes; não infira vivacidade de um limiar de segurança.
  7. Mapeie a prova para a implantação. Confira versões de clientes, mudanças de parâmetros, concentração de membros e stake, custódia de chaves, diversidade de pares, papéis de builder ou sequenciador, checkpoints, regras de subjetividade fraca, reorganização e política de confirmação da aplicação.

FLP não diz que consenso implantado é impossível. Diz que, em um modelo de mensagens totalmente assíncrono, até uma falha por parada deixa alguma execução admissível em que um protocolo determinístico não termina. Protocolos reais obtêm garantias úteis ao adicionar sincronia ou sincronia parcial, escolhas aleatórias, detectores de falha, premissas econômicas ou promessas de terminação mais fracas. Essas adições devem ser nomeadas, não escondidas por um rótulo.

Exemplos resolvidos

1. Validade não é ordenação canônica

Uma saída não gasta U vale 1 BTC. A transação T_B a gasta para Bob e T_C gasta a mesma saída para Carol. Em relação ao mesmo estado pai, cada uma pode ter assinatura e formato corretos, mas um histórico válido não pode consumir U duas vezes.

Se blocos válidos concorrentes contêm uma transação cada, a validação mantém localmente ambas as ramificações candidatas e a escolha de fork seleciona uma canônica. Quando T_B entra no histórico escolhido, T_C conflita com o estado resultante. O consenso escolheu uma ordem; não consertou assinatura ruim nem decidiu quem merecia moralmente o pagamento.

2. Trabalho acumulado, não número de nós

Suponha duas ramificações válidas ao estilo Bitcoin com trabalho acumulado W_A=240 e W_B=235 na mesma unidade arbitrária. Um nó validador escolhe A pela regra do trabalho acumulado mesmo que tenha ouvido B primeiro de mais pares. Contagem de pares não é peso de consenso.

Se B ganha depois 10 unidades e A nenhuma, fica W_B=245 contra W_A=240, então o nó pode reorganizar para B após validar a ramificação. Essa aritmética simplificada mostra por que confirmação PoW é probabilística: substituir histórico profundo fica progressivamente mais caro, não logicamente impossível após um número fixo de blocos.

3. Quórum BFT ponderado e interrupção de vivacidade

Considere peso validador total 100 e um compromisso ao estilo CometBFT que exige pré-compromissos >2/3 para o mesmo bloco, altura e rodada. Peso inteiro 67 passa. Dois quóruns de peso 67 se cruzam em pelo menos 34, pois 67 + 67 - 100 = 34. Se o peso bizantino for inferior a um terço, a interseção contém peso honesto que não deve assinar compromissos conflitantes.

O mesmo limiar revela uma fronteira de vivacidade. Se peso 34 ficar offline, só 66 resta e nenhum compromisso se forma mesmo que todos online sejam honestos. O protocolo pode parar preservando segurança; voto de governança ou número de operadores não substitui o peso ausente.

4. Escolha de fork e finalidade de checkpoints são distintas

Em um traço simplificado do Gasper, sejam C_0, C_1 e seu filho direto C_2 checkpoints. Votos representando 67/100 do saldo efetivo ativo podem criar um vínculo de supermaioria de C_0 para C_1, justificando C_1. Outro vínculo qualificado de C_1 para C_2 pode finalizar o checkpoint anterior sob a regra FFG aplicável.

Entre checkpoints, LMD-GHOST usa as atestações mais recentes para escolher a cabeça entre descendentes viáveis do checkpoint justificado, enquanto restrições do checkpoint finalizado filtram ramificações incompatíveis. Escolha de cabeça, justificação e finalização são transições relacionadas, mas distintas; “67% votou neste bloco” não descreve nenhuma por completo.

Riscos e falhas de revisão

Modelo e garantias

  • Dizer “a rede chegou a consenso” sem definir decisão, segurança, vivacidade, validade e terminação.
  • Tratar Proof of Work, Proof of Stake, mineração, staking ou percentual de voto como especificação completa.
  • Aplicar 51%, 2/3 ou n=3f+1 universalmente a modelos diferentes de falha, tempo, peso e finalidade.
  • Misturar parada, comportamento bizantino, roubo de chaves, canais defeituosos, software correlacionado e captura de governança.
  • Invocar FLP como proibição do consenso prático em vez de seu escopo determinístico, totalmente assíncrono e de terminação garantida.
  • Contar nós ou chaves sem medir operadores independentes, peso, clientes, nuvens e custódia.
  • Supor que canônico, safe, justificado, comprometido e finalizado sejam estados intercambiáveis.
  • Inferir verdade externa, ordenação justa, privacidade, descentralização ou valor a partir de acordo replicado.

Protocolo e implementação

  • Aceitar blocos ou votos sem vincular cadeia, versão, altura, rodada, pai, carga, remetente e época de membros.
  • Permitir divergência entre implementações em transição, serialização, domínio de assinatura, escolha, desempate ou arredondamento.
  • Verificar certificado sem reconstruir snapshot de peso elegível e tratamento de signatários duplicados.
  • Reproduzir votos, trabalho ou certificados entre forks, redes, rodadas, atualizações ou mudanças de validadores.
  • Atualizar incorretamente travas, checkpoints justificados ou certificados mais altos em timeout, troca de visão ou recuperação.
  • Tratar cabeça local ou rótulo de um único RPC como evidência independente de finalidade da rede.
  • Testar só o caminho feliz, não atraso, partição, equivocação, proposta inválida, reorganização e recuperação.

Implantação e aplicação

  • Concentrar hash, stake, clientes, relays, builders, sequenciadores, nuvens ou assinatura sob identidades nominalmente separadas.
  • Definir timeouts ou intervalos abaixo do tempo real de propagação e validação, prejudicando vivacidade ou aumentando forks.
  • Creditar depósitos, emitir ativos de ponte ou executar ações irreversíveis antes da finalidade necessária de origem e aplicação.
  • Supor que slashing, recompensas ou preço do token sempre criam orçamento de segurança suficiente e líquido.
  • Usar recuperação social ou governança sem reconhecer quem coordena, qual cadeia os clientes instalam e qual garantia anterior mudou.

Equívocos comuns

  • Consenso e validação são iguais. Validação rejeita dados contra as regras; consenso escolhe decisões compatíveis entre candidatos talvez válidos localmente.
  • Mais nós significam automaticamente mais segurança. Influência, independência, topologia, diversidade de software e modelo de falha importam mais que a contagem bruta.
  • Um atacante de 51% pode forjar qualquer assinatura. Recurso majoritário pode permitir censura ou reorganização em certo protocolo, mas não revela chaves nem autoriza gastos inválidos.
  • Dois terços sempre significam finalidade. Desigualdade, mensagem, rodada, snapshot de peso, regra de trava e condição de finalidade são específicas do protocolo.
  • Blocos rápidos provam consenso forte. Intervalos curtos podem elevar disputas de propagação e pressão de recursos; avalie latência junto de segurança, vivacidade e finalidade.

Tópicos relacionados

Fontes

Navegação

Pesquisar na wiki...