Criptomoedas e Web3 · Explicador

Como funcionam os mecanismos de consenso

Toda blockchain precisa que computadores que não se conhecem concordem sobre a mesma lista de transações. Veja as grandes famílias de consenso, o que cada uma garante e o que cada uma sacrifica.

Editor responsável:
Daniel Ferreira

Publicado em · 11 min de leitura

Também disponível em: English

Em três pontos

  • Consenso é o conjunto de regras que faz vários nós manterem o mesmo registro, na mesma ordem, mesmo com falhas; as famílias diferem no tipo de falha que toleram e em quem pode participar.
  • Protocolos BFT clássicos, como PBFT e Tendermint, dão finalidade imediata com até um terço de participantes maliciosos, mas exigem um conjunto conhecido de validadores; o consenso de Nakamoto aceita qualquer um, ao custo de finalidade probabilística.
  • Prova de participação, prova de autoridade e DAG são variações sobre os mesmos dilemas: segurança, continuidade, finalidade e permissão nunca vêm todas de graça.

Uma blockchain é, por baixo, um registro copiado em muitos computadores. Para que essas cópias valham alguma coisa, todos precisam concordar sobre quais transações entram e em que ordem. As regras que produzem esse acordo formam o mecanismo de consenso.

A ethereum.org define o termo de forma ampla: é o conjunto completo de ideias, protocolos e incentivos que permite a um grupo distribuído de nós concordar sobre o estado da rede. E faz uma ressalva importante: prova de trabalho e prova de participação, sozinhas, “não são protocolos de consenso” (ethereum.org, Consensus mechanisms). Elas são uma peça, a que impede alguém de dominar a votação criando identidades falsas. A outra peça é a regra que escolhe a cadeia correta quando há versões concorrentes.

Este texto apresenta as grandes famílias de consenso e as trocas entre elas. A comparação detalhada entre prova de trabalho e prova de participação está em Proof of Work ou Proof of Stake; aqui o foco é o mapa geral.

O problema que todo consenso resolve

A ciência da computação estuda esse problema desde muito antes do Bitcoin. O nome técnico é replicação de máquina de estado: vários servidores começam no mesmo estado e executam os mesmos comandos na mesma ordem. Como os comandos são determinísticos, todos chegam ao mesmo resultado. O papel do consenso é garantir que todos recebam os comandos na mesma ordem (Ongaro e Ousterhout, Raft).

A dificuldade está nas falhas. Há dois tipos que importam:

  • Falha por parada (crash): o computador simplesmente para de responder. Ele pode voltar depois, mas nunca mente.
  • Falha bizantina: o computador se comporta de forma arbitrária. Pode enviar mensagens contraditórias, mentir ou agir de má-fé. O nome vem de um problema clássico sobre generais bizantinos que precisam combinar um ataque sem saber quais deles são traidores.

O artigo que apresenta o Tendermint descreve bem a mudança que as criptomoedas trouxeram. Antes, a replicação rodava em data centers, com três a sete réplicas de uma mesma organização, e tratava só falhas por parada. Com as blockchains, o desafio passou a ser chegar a acordo pela internet, entre centenas ou milhares de nós de donos diferentes, alguns possivelmente maliciosos (Buchman, Kwon e Milosevic, arXiv).

Quatro perguntas para avaliar qualquer mecanismo

Antes de ver as famílias, vale ter uma régua. Quatro propriedades resumem o que um mecanismo entrega:

  • Segurança (safety): nós honestos nunca registram versões conflitantes. Nada de errado acontece.
  • Continuidade (liveness, também traduzida como vivacidade): a rede continua aceitando transações novas. Algo de útil acaba acontecendo.
  • Finalidade: o momento a partir do qual uma transação não pode mais ser revertida.
  • Permissão: quem pode participar do consenso. Qualquer um, ou só nós autorizados.

Em geral, nenhum mecanismo maximiza as quatro ao mesmo tempo. As famílias abaixo são, em boa parte, escolhas diferentes sobre o que priorizar.

Raft: consenso para quem confia nos participantes

O Raft foi publicado em 2014 por Diego Ongaro e John Ousterhout, da Universidade Stanford, com um objetivo declarado: ser mais fácil de entender do que o Paxos, o algoritmo que dominava a área. Um líder recebe os comandos e os replica nos demais servidores. Se o líder cai, um novo é eleito com temporizadores aleatórios (Ongaro e Ousterhout, Raft).

As garantias são claras:

  • a segurança vale em quaisquer condições não bizantinas, inclusive atrasos e perda de mensagens;
  • a rede funciona enquanto a maioria dos servidores estiver no ar. Um grupo de cinco tolera a queda de dois.

O limite também é claro: o Raft não foi feito para participantes mal-intencionados. Por isso aparece em ambientes onde todos os operadores são confiáveis. O Hyperledger Fabric, plataforma de redes corporativas, usa o Raft como serviço de ordenação recomendado para produção e o classifica como tolerante a falhas por parada, não a falhas bizantinas (Hyperledger Fabric, Ordering Service).

Família BFT: acordo com até um terço de traidores

BFT é a sigla de Byzantine fault tolerance, tolerância a falhas bizantinas. O trabalho que tornou essa família viável na prática foi o PBFT, de Miguel Castro e Barbara Liskov, do MIT, apresentado em 1999 (Castro e Liskov, USENIX OSDI 99).

O PBFT funciona com um número fixo de réplicas que se conhecem. Para tolerar f réplicas maliciosas, são necessárias 3f + 1 réplicas no total. Com quatro, tolera-se uma; com sete, duas. Uma réplica, chamada primária, propõe a ordem das requisições, e as demais confirmam em três fases: pré-preparação, preparação e confirmação. Se a primária falhar ou agir mal, as outras trocam de primária, numa troca de visão (view change).

Por que um terço? A demonstração do Tendermint resume o argumento: com 3f + 1 participantes, dois grupos quaisquer de 2f + 1 se sobrepõem em pelo menos f + 1 membros, ou seja, em pelo menos um honesto. Esse honesto impede que os dois grupos aprovem decisões conflitantes.

O PBFT também mostrou que o custo podia ser baixo. Segundo os autores, um serviço de arquivos em rede (NFS) replicado com o algoritmo ficou apenas 3% mais lento que a versão sem replicação.

O Tendermint, descrito em 2018 por Ethan Buchman, Jae Kwon e Zarko Milosevic, adaptou essa família às blockchains. Ele se inspira no PBFT, decide em três etapas de comunicação quando tudo corre bem e usa comunicação por fofoca (gossip) entre pares, adequada a redes em que cada nó fala só com alguns vizinhos. A premissa é que os participantes maliciosos somem menos de um terço do poder de voto (Buchman, Kwon e Milosevic, arXiv).

O mesmo princípio aparece em redes corporativas. No Hyperledger Besu, os protocolos QBFT e IBFT 2.0 exigem no mínimo quatro validadores, precisam de dois terços deles ativos para continuar produzindo blocos e oferecem finalidade imediata: segundo a documentação, não há bifurcações e todo bloco válido entra na cadeia principal (Hyperledger Besu, Proof of authority consensus). O Fabric passou a oferecer um serviço de ordenação BFT a partir da versão 3.0.

As trocas da família BFT:

  • A favor: finalidade imediata e segurança mesmo com participantes maliciosos, dentro do limite de um terço.
  • Contra: o conjunto de validadores precisa ser conhecido. A documentação do Besu registra outro custo: o tempo de bloco aumenta conforme cresce o número de validadores. E, se mais de um terço parar de responder, a rede para de decidir. O protocolo prefere parar a errar.

Consenso de Nakamoto: aberto a qualquer um

O Bitcoin resolveu um problema que a família BFT não resolvia: chegar a acordo sem saber quem são nem quantos são os participantes.

A solução tem duas partes, descritas no whitepaper (Nakamoto, whitepaper do Bitcoin):

  • Voto atrelado a recurso. Se cada endereço de internet valesse um voto, bastaria criar muitos endereços. Com a prova de trabalho, o voto vira “uma CPU, um voto”.
  • Regra da cadeia mais longa. Os nós sempre consideram correta a cadeia com mais trabalho acumulado. Se dois blocos surgem ao mesmo tempo, cada nó trabalha no primeiro que recebeu e guarda o outro; o empate se desfaz quando o próximo bloco aparece.

O resultado é um consenso em que os nós “votam com seu poder de processamento”, podem entrar e sair quando quiserem e não precisam ser identificados. A segurança depende de a maioria do poder de processamento ser honesta. O mecanismo da mineração está em como funciona a mineração de Bitcoin, e a estrutura da cadeia, em como funciona a blockchain do Bitcoin.

A troca está na finalidade. Ela é probabilística: um bloco recente pode ser substituído se outra versão da cadeia ficar mais longa. O NIST observa que, por isso, a maioria dos usuários espera alguns blocos antes de considerar uma transação válida (NIST, NISTIR 8202).

Na leitura da redação, o consenso de Nakamoto e a família BFT fazem escolhas opostas diante de uma rede dividida. O BFT prefere parar a correr o risco de duas versões. O Nakamoto continua produzindo blocos dos dois lados e resolve a divergência depois, quando uma cadeia ultrapassa a outra.

Prova de participação e suas variantes

Na prova de participação, o recurso que dá direito a voto é moeda da própria rede, depositada como garantia. Segundo o NIST, a chance de um participante publicar o próximo bloco é proporcional à fatia que ele depositou em relação ao total.

O NIST registra um problema clássico desse modelo, o nada a perder (nothing at stake): se houver duas cadeias concorrentes, votar nas duas não custa nada, e um participante pode fazer isso para aumentar a chance de ser recompensado. Isso pode manter bifurcações abertas por muito tempo.

A resposta do Ethereum é a punição. Um validador deposita 32 ETH e, se assinar dois blocos para o mesmo intervalo ou der votos contraditórios, perde parte ou todo o depósito, o chamado slashing (ethereum.org, Proof-of-stake).

O protocolo atual do Ethereum, o Gasper, é um híbrido das duas famílias anteriores:

  • uma regra de escolha de bifurcação, parente da cadeia mais longa, que pondera cada cadeia pelos votos recebidos;
  • um mecanismo de finalidade de estilo BFT, o Casper FFG, proposto por Vitalik Buterin e Virgil Griffith em 2017 como uma camada de finalidade que se sobrepõe a uma cadeia existente (Buterin e Griffith, arXiv).

Quando validadores que somam dois terços do ether depositado votam em blocos de controle sucessivos, o anterior fica finalizado. Revertê-lo exigiria destruir ao menos um terço de todo o ether depositado. Se a finalização trava por mais de quatro épocas, entra o vazamento por inatividade: validadores que não votam com a maioria perdem depósito aos poucos até que a maioria volte a somar dois terços (ethereum.org, Gasper). É uma forma de recuperar a continuidade sem abrir mão da segurança.

Outras variantes:

  • Ouroboros, de Aggelos Kiayias e coautores (2016), apresentado pelos autores como o primeiro protocolo de prova de participação com garantias formais de segurança, comparáveis às do Bitcoin (Kiayias et al., IACR ePrint 2016/889).
  • Prova de participação delegada (DPoS): os detentores de moeda elegem delegados que produzem os blocos. A tabela comparativa do NIST lista como vantagem a eficiência e, como desvantagens, menos diversidade de nós, maior risco de comprometimento por haver poucos operadores e possível incentivo a conluio e suborno entre delegados conhecidos.

Prova de autoridade e outros modelos permissionados

Na prova de autoridade (PoA), quem produz blocos é um grupo de signatários autorizados, escolhidos pela reputação, normalmente organizações conhecidas. A ethereum.org descreve o funcionamento do Clique, a implementação padrão no Ethereum: os signatários se revezam e cada um só pode produzir um bloco a cada tantos, o que limita o dano de um signatário malicioso enquanto os outros votam para removê-lo (ethereum.org, Proof-of-authority).

  • A favor: confirmação rápida, segundo a ethereum.org potencialmente abaixo de um segundo, e custo baixo.
  • Contra: poucos validadores, logo mais centralização, e signatários maliciosos ainda podem reorganizar a cadeia ou censurar transações. É usada sobretudo em redes privadas, redes de teste e desenvolvimento.

O NIST descreve ainda dois modelos para redes permissionadas (NIST, NISTIR 8202):

  • Rodízio (round robin): os nós se revezam na criação de blocos. É simples e barato, mas exige muita confiança; numa rede aberta, um atacante poderia criar nós extras para ganhar mais vezes.
  • Prova de tempo decorrido (PoET): cada nó recebe um tempo de espera aleatório de um componente de hardware seguro, e quem acorda primeiro publica. O modelo depende de que esse hardware não tenha sido comprometido.

A diferença entre redes abertas e fechadas, e por que elas escolhem mecanismos diferentes, é o tema de blockchain pública versus blockchain privada.

DAG: quando o registro deixa de ser uma fila

Alguns sistemas abandonam a cadeia linear. Em vez de cada bloco apontar para um único antecessor, transações ou blocos formam um grafo acíclico dirigido (DAG, na sigla em inglês): uma rede de referências que podem ser criadas em paralelo, sem nunca formar ciclos.

Uma revisão acadêmica de 2020, de Qin Wang e coautores, resume a motivação: cadeias lineares têm latência alta e escalabilidade limitada, e o DAG busca confirmação rápida e processamento paralelo sem enfraquecer muito a segurança (Wang et al., arXiv). O mesmo trabalho analisa segurança e desempenho de vários sistemas e aponta desafios ainda em aberto. Na avaliação da redação, o DAG é uma estrutura de dados, não um mecanismo de consenso completo: cada sistema ainda precisa de regras para decidir a ordem final.

Comparação resumida

Família Quem participa Falhas toleradas Finalidade Principal custo
Raft Nós conhecidos e confiáveis Parada de até a minoria Imediata Não resiste a nós maliciosos
BFT (PBFT, Tendermint, QBFT) Validadores conhecidos Menos de 1/3 maliciosos Imediata Para se 1/3 sai do ar; conjunto fechado
Nakamoto (prova de trabalho) Qualquer um Minoria do poder de processamento Probabilística Energia; espera por confirmações
Prova de participação (Ethereum) Qualquer um com depósito Reverter a finalidade custa ao menos 1/3 do depósito Após checkpoints Complexidade; capital travado
Prova de autoridade Signatários autorizados Minoria dos signatários Rápida Centralização
DAG Varia por sistema Varia por sistema Varia por sistema Desenho ainda em pesquisa

Os números da tabela são as premissas de cada protocolo, conforme as fontes citadas. Na prática, a segurança também depende da implementação, dos incentivos e de quantos participantes de fato controlam a rede.

O que levar deste texto

  • Consenso é o que faz muitas cópias de um registro continuarem iguais, na mesma ordem, mesmo quando alguns participantes falham ou mentem.
  • Raft tolera quedas, não traições. A família BFT tolera até um terço de participantes maliciosos e dá finalidade imediata, mas exige validadores conhecidos.
  • O consenso de Nakamoto abriu a participação a qualquer um, trocando finalidade imediata por finalidade probabilística.
  • A prova de participação do Ethereum combina as duas tradições: escolha de cadeia no estilo Nakamoto e finalidade no estilo BFT, com punição para quem vota em versões conflitantes.
  • Prova de autoridade, rodízio e PoET servem a redes permissionadas, onde a confiança vem da identidade dos participantes.

Fontes

  1. Consensus mechanisms, ethereum.org. Acesso em 8 de outubro de 2026
  2. NISTIR 8202: Blockchain Technology Overview, National Institute of Standards and Technology (NIST). Acesso em 8 de outubro de 2026
  3. In Search of an Understandable Consensus Algorithm (Extended Version), Diego Ongaro e John Ousterhout (Stanford University). Publicado em 20 de maio de 2014 · Acesso em 8 de outubro de 2026
  4. Practical Byzantine Fault Tolerance, Miguel Castro e Barbara Liskov (USENIX OSDI 99). Acesso em 8 de outubro de 2026
  5. The latest gossip on BFT consensus, Ethan Buchman, Jae Kwon e Zarko Milosevic (arXiv). Publicado em 13 de julho de 2018 · Acesso em 8 de outubro de 2026
  6. Proof of authority consensus, Hyperledger Besu (documentação oficial). Acesso em 8 de outubro de 2026
  7. The Ordering Service, Hyperledger Fabric (documentação oficial). Acesso em 8 de outubro de 2026
  8. Bitcoin: A Peer-to-Peer Electronic Cash System, Satoshi Nakamoto (bitcoin.org). Acesso em 8 de outubro de 2026
  9. Proof-of-stake (PoS), ethereum.org. Acesso em 8 de outubro de 2026
  10. Gasper, ethereum.org. Acesso em 8 de outubro de 2026
  11. Casper the Friendly Finality Gadget, Vitalik Buterin e Virgil Griffith (arXiv). Publicado em 25 de outubro de 2017 · Acesso em 8 de outubro de 2026
  12. Ouroboros: A Provably Secure Proof-of-Stake Blockchain Protocol, Aggelos Kiayias, Alexander Russell, Bernardo David e Roman Oliynykov (IACR ePrint). Acesso em 8 de outubro de 2026
  13. Proof-of-authority (PoA), ethereum.org. Acesso em 8 de outubro de 2026
  14. SoK: Diving into DAG-based Blockchain Systems, Qin Wang, Jiangshan Yu, Shiping Chen e Yang Xiang (arXiv). Publicado em 11 de dezembro de 2020 · Acesso em 8 de outubro de 2026

Leia também

Criptomoedas e Web3 · Explicador

Rastreamento de transações e análise on-chain

Como toda transação de uma blockchain pública fica registrada, é possível seguir o caminho do dinheiro. Entenda como esse rastreamento funciona, por que ele depende de suposições e quem pode usá-lo.

Criptomoedas e Web3 · Explicador

Auditoria de smart contracts: método e limites

Auditoria reduz o risco de um contrato inteligente, mas não o elimina. Entenda o que os auditores examinam, com quais ferramentas, e o que fica fora do alcance deles.

Criptomoedas e Web3 · Explicador

Por que o Bitcoin tem oferta limitada

O limite de 21 milhões de bitcoins não está escrito em um contrato nem depende de um banco central. Ele é consequência de uma regra de emissão no código, verificada por cada computador da rede.