﻿---
title: "Ataque de 51%"
description: "Um ataque de 51% ocorre quando uma parte controla poder de consenso suficiente para superar de modo confiável a rede honesta e reorganizar o histórico recente da blockchain."
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.

# Ataque de 51%

> Somente para fins educacionais; não constitui aconselhamento de investimento. Investir pode resultar em perdas.

<a id="answer"></a>

## Resposta direta

Um ataque de 51% ocorre quando uma parte controla poder de consenso suficiente para superar de modo confiável a rede honesta e reorganizar o histórico recente da blockchain.

Em uma blockchain de prova de trabalho (PoW), o termo normalmente significa o controle da maioria da taxa de hash ativa. O invasor pode construir uma ramificação concorrente com mais prova de trabalho acumulada que a ramificação honesta e fazer com que os nós a adotem. “51%” é uma forma abreviada de indicar uma vantagem sustentada, não um gatilho universal: um invasor com menos taxa de hash às vezes consegue reorganizar por acaso um bloco pouco profundo, enquanto um poder majoritário temporário não garante um ataque lucrativo.

O rótulo não deve ser transferido mecanicamente para a prova de participação (PoS). Limiares de votação, regra de escolha da bifurcação, finalidade, penalidades por inatividade e slashing são específicos de cada protocolo. Por exemplo, a documentação do Ethereum descreve consequências diferentes em torno de 33%, 34%, 51% e 66% da participação. A pergunta relevante é sempre qual regra de consenso e qual objetivo de ataque estão em discussão.

<a id="mechanism"></a>

## Como funciona

Os nós PoW aceitam apenas blocos válidos e seguem a ramificação válida com o maior trabalho acumulado. Um invasor majoritário não pode tornar válida uma assinatura inválida nem criar moedas fora das regras do protocolo. Ele pode, porém, minerar em particular uma ramificação válida conflitante e revelá-la depois que ela ultrapassar a ramificação pública.

Uma sequência típica de gasto duplo é:

1. O invasor paga um comerciante ou uma exchange na cadeia pública enquanto minera em particular uma ramificação que gasta as mesmas moedas em outro lugar.
2. O destinatário aguarda as confirmações e então libera os bens ou permite um saque.
3. Se a ramificação privada acumular mais trabalho, o invasor a publica. Os nós se reorganizam para essa ramificação, e o pagamento original desaparece do histórico aceito.

Cada confirmação adicional dá à ramificação honesta uma vantagem maior. Quando o invasor tem menos taxa de hash que a rede honesta, a probabilidade de alcançá-la diminui à medida que essa vantagem aumenta; com uma maioria sustentada, o invasor consegue superar de modo confiável a ramificação honesta ao longo do tempo. As confirmações reduzem o risco, mas não criam finalidade absoluta.

O mesmo controle pode ser usado para censurar ou atrasar transações selecionadas, reordenar transações recentes e interromper confirmações. Ele não permite roubar moedas protegidas pela chave privada de outra pessoa, gastar moedas que não pertencem ao invasor nem forçar nós completos a aceitar blocos que violem as regras de consenso.

<a id="example"></a>

## Exemplo

Suponha que uma pequena rede PoW ilustrativa tenha 1 TH/s de taxa de hash honesta. Um invasor pode alugar 1.2 TH/s por $20,000 por hora, o que lhe dá cerca de 54.5% dos 2.2 TH/s combinados enquanto o aluguel estiver ativo. O invasor deposita tokens no valor de $200,000 em uma exchange e, ao mesmo tempo, minera uma ramificação privada com um gasto conflitante.

Se a exchange creditar o depósito após 10 blocos, ou cerca de 20 minutos nessa cadeia hipotética, o invasor poderá sacar outro ativo antes de publicar a ramificação privada. Um aluguel de duas horas custa $40,000, mas esse valor não é o lucro do invasor. Taxas de negociação, slippage, falha na execução, congelamento de saques, detecção e uma queda no preço do ativo atacado podem tornar a tentativa não lucrativa.

Se a exchange elevar sua exigência para 200 blocos, o invasor precisará sustentar a ramificação concorrente por muito mais tempo. Com o intervalo de bloco presumido de dois minutos, isso representa cerca de 6 horas e 40 minutos de tempo de confirmação. O ataque fica mais caro e mais fácil de detectar, enquanto clientes legítimos também esperam mais. Portanto, uma política de confirmação contrapõe velocidade de liquidação e risco de reorganização.

<a id="risks"></a>

## Riscos e controles

Os alvos mais expostos são pagamentos recentes e de alto valor que podem ser convertidos ou sacados antes que um operador reaja. Reescrever o histórico de milhares de blocos atrás exigiria refazer todo o trabalho posterior e ultrapassar a cadeia ativa; por isso, ataques práticos geralmente se concentram em uma janela curta e valiosa.

A segurança econômica depende de mais que a capitalização de mercado de um token. Entre os fatores relevantes estão a taxa de hash disponível para aluguel, a oferta de hardware especializado, os custos de eletricidade e coordenação, a concentração de pools de mineração, as recompensas por bloco, a liquidez do mercado e o valor que um destinatário libera após a confirmação. A concentração de pools é um sinal de alerta, mas os operadores dos pools não necessariamente possuem os equipamentos dos mineradores; estes podem redirecionar sua taxa de hash.

Destinatários e operadores de infraestrutura podem reduzir a exposição ao:

- definir requisitos de confirmação de acordo com o valor da transação e as condições atuais da rede;
- monitorar ramificações concorrentes, mudanças incomuns na taxa de hash e reorganizações profundas;
- pausar depósitos ou saques quando o risco de reorganização aumentar; e
- limitar quanto valor irreversível pode sair durante uma única janela de confirmação.

Esses controles reduzem a perda esperada; nenhum deles torna uma liquidação PoW probabilística matematicamente irreversível.

<a id="misconceptions"></a>

## Equívocos comuns

### Mito 1: Um invasor precisa de exatamente 51.0%

Não. Abaixo de 50%, um invasor ainda pode alcançar a cadeia por acaso, especialmente a partir de uma desvantagem pequena, mas a probabilidade diminui conforme as confirmações se acumulam. Acima de 50%, o controle sustentado da taxa de hash dá ao invasor uma vantagem esperada no longo prazo. Duração, condições da rede, custo e objetivo escolhido continuam sendo importantes.

### Mito 2: O poder de hash majoritário pode roubar todas as moedas

Não. O poder de consenso afeta qual histórico válido é selecionado; ele não revela chaves privadas nem autoriza gastos inválidos. Um invasor majoritário obtém principalmente a capacidade de reverter os próprios pagamentos recentes, censurar transações e reordenar blocos recentes.

### Mito 3: Uma quantidade fixa de confirmações é sempre segura

Nenhuma quantidade fixa é adequada para todas as redes ou pagamentos. O risco depende da taxa de hash disponível ao invasor, do orçamento de segurança da rede honesta, do valor da transação, do tempo de detecção e resposta e da rapidez com que o ativo recebido pode ser sacado ou convertido.

<a id="related"></a>

## Tópicos relacionados

- [Reorganização da cadeia (reorg)](/pt-br/crypto/chain-reorg/)
- [Uma assinatura de delegação de governança é segura?](/pt-br/crypto/governance-delegation-signature-risk/)
- [Taxa de hash](/pt-br/crypto/hashrate/)
- [Staking líquido](/pt-br/crypto/liquid-staking/)
- [Prova de trabalho (PoW)](/pt-br/crypto/proof-of-work/)

<a id="sources"></a>

## Fontes

- [Bitcoin: A Peer-to-Peer Electronic Cash System](https://bitcoin.org/bitcoin.pdf) - Bitcoin.org (acessado em: 2026-08-20)
- [Block Chain](https://developer.bitcoin.org/devguide/block_chain.html) - Bitcoin Developer Guide (acessado em: 2026-08-20)
- [Proof-of-stake attack and defense](https://ethereum.org/developers/docs/consensus-mechanisms/pos/attack-and-defense/) - Ethereum.org (acessado em: 2026-08-20)

Source: https://wiki.fcontext.com/pt-br/crypto/fifty-one-percent-attack/index.mdx
