Sistemas Descentralizados/02 - Web33 min
Consenso e Finalidade
- Que problema isso resolve?
- Quando usar / quando NÃO usar?
- Qual o principal trade-off?
- Como isso falha em produção?
Conceito
Consenso é fazer nós independentes concordarem sobre uma ordem única de eventos, mesmo com falhas e mentiras. Note bem: o difícil não é concordar sobre o quê aconteceu — é sobre a ordem.
Por que a ordem é o problema
Duas transações gastando a mesma moeda são individualmente válidas. Só se tornam inválidas em relação uma à outra, e qual delas vale depende de qual veio primeiro. Como 1. O que é um Sistema Distribuído mostra, não existe relógio global — então "primeiro" não é um fato observável, é algo que precisa ser decidido coletivamente.
Esse é o problema do gasto duplo (double-spend), e é a razão pela qual blockchain precisa de consenso. Guarde essa ideia: em 1. Nostr vs Blockchain ela é o critério que separa os dois mundos.
Finalidade: quando dá para confiar
Finalidade é a garantia de que uma transação não vai mais ser revertida. Existem dois sabores, e confundi-los causa perda de dinheiro real:
Finalidade probabilística (Bitcoin, PoW). Nunca há certeza absoluta — só a probabilidade de reversão caindo exponencialmente a cada bloco. A regra prática das "6 confirmações" é, em vocabulário de sistemas distribuídos, exatamente isto:
a janela de inconsistência com risco decaindo exponencialmente
Não é número mágico: é uma escolha de risco. Um café aceita 0 confirmações; uma transferência de milhões espera bem mais.
Finalidade determinística (Ethereum PoS, BFT). Depois que 2/3 do stake atesta um checkpoint, reverter exigiria que os validadores destruíssem o próprio capital (slashing). A garantia deixa de ser probabilística e vira econômica: é possível, mas ninguém racional faz.
Blockchain sob o CAP
Aqui a coisa fica interessante e conecta direto com CAP Theorem. A resposta não é a mesma para toda cadeia:
Bitcoin sob partição — continua disponível dos dois lados: cada metade da rede segue minerando sua própria cadeia. Isso é divergência, ou seja, um fork. Quando a partição cura, a regra da cadeia mais longa (maior trabalho acumulado) reconcilia, e o lado perdedor é descartado.
Traduzindo para o vocabulário da sua nota de Eventual Consistency: Bitcoin é AP com consistência eventual, e o mecanismo de resolução de conflito é uma variante de Last-Write-Wins — só que o "timestamp" que desempata é trabalho computacional acumulado, não o relógio de ninguém. E, como todo LWW, ele descarta escritas silenciosamente: as transações do lado perdedor simplesmente deixaram de ter acontecido.
Ethereum PoS sob partição — continua produzindo blocos, mas para de finalizar se não houver 2/3 do stake alcançável. Ou seja: AP na ponta, CP na finalidade. Duas garantias diferentes convivendo na mesma cadeia, escolhidas por camada.
Sob PACELC, no caso normal (sem partição), toda blockchain escolhe deliberadamente consistência sobre latência — daí os minutos de espera.
Trade-offs
O trade-off do consenso aberto, resumido:
| Você quer | Paga em |
|---|---|
| Ordem global acordada | latência (minutos, não ms) |
| Resistência a Sybil | energia (PoW) ou capital travado (PoS) |
| Verificação independente | throughput limitado ao nó mais fraco |
| Finalidade rápida | suposições mais fortes sobre a rede |
Há um trade-off menos citado e mais perigoso: a segurança do consenso aberto é econômica, não matemática. Um ataque de 51% não é impossível — é caro. Se o valor de atacar superar o custo de atacar, o sistema quebra. Cadeias pequenas com pouco hashrate já sofreram isso na prática.
Exemplo prático
Uma exchange que aceita depósito com 1 confirmação, numa cadeia pequena.
O atacante deposita, o site credita após 1 bloco, ele troca por outra moeda e saca. Em seguida publica uma cadeia alternativa mais longa — que ele minerou em paralelo e na qual o depósito nunca existiu. A rede aceita a cadeia mais longa, o depósito desaparece, o saque não.
Nada foi "hackeado". O protocolo funcionou exatamente como especificado. A exchange é que leu finalidade probabilística como se fosse determinística.
A lição vale fora de cripto: sempre pergunte se a garantia que você está usando é "não vai reverter" ou "provavelmente não vai reverter" — e, no segundo caso, quanto vale o "provavelmente".
Relacionado
Parte de MOC Web3 · ethereum.org — consensus