---
title: "Prova de falha (prova de fraude)"
description: "Guia sensível à implantação sobre provas de falha otimistas, alegações contestadas, bisseção de traços, verificação de passo único, relógios, cauções, disponibilidade de dados, finalidade de saques e verificação operacional."
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.
# Prova de falha (prova de fraude)
> Somente para fins educacionais; não constitui recomendação nem aconselhamento de investimento. Investir pode causar perdas.
## Resposta direta
Uma prova de falha, também chamada de prova de fraude, é um processo de protocolo para contestar uma alegação otimista sobre computação ou estado. O proponente não prova cada transição antes da aceitação; um desafiante elegível pode apresentar um traço conflitante dentro dos relógios definidos, e o contrato de liquidação resolve a divergência com um verificador especificado. Muitos modelos interativos reduzem repetidamente um traço longo a uma única instrução em disputa e executam esse caso-base on-chain.
O nome não prova que a implantação seja permissionless, esteja operacional ou seja segura. A segurança exige os dados exatos de derivação, ao menos um desafiante correto que reconstrua a alegação e aja no prazo, acesso e gas suficientes na cadeia de liquidação, programas e contratos corretos e governança incapaz de contornar o resultado. Uma alegação que sobreviva ao jogo pode autorizar um saque conforme as regras daquela implantação; não prova retroativamente toda transação L2, afirmação do frontend ou resultado econômico.
## Como funciona
1. Fixe a implantação: IDs L1 e L2, versões do rollup e da prova, hashes, fábrica, portal ou bridge, programa, VM, tipo de jogo, implementações e administradores, permissões, cauções, profundidade, relógios, atrasos, pausa e finalidade. O rótulo `fraud proof` não é uma especificação comum entre rollups.
2. Reconstrua a alegação com entradas autenticadas. Registre estado âncora, head L1, bloco L2 ou output root contestado, lote e blobs, configuração, pré-estado, raiz de saques e regras de derivação. Uma state root não basta; dados indisponíveis podem inviabilizar uma contestação aberta.
3. Verifique se o jogo foi criado e afeta o objeto pretendido. Confira root claim, proponente, bloco e horário, tipo, status respeitado ou bloqueado, caução, elegibilidade e regra real do portal. Separe alegação pendente, resultado do jogo e output apto a saque.
4. Reexecute com nó e implementação independentes. Compare o traço correto com cada alegação e preserve preimages, testemunhos e versões. No jogo interativo, ataque ou defenda o intervalo correto até isolar uma instrução e envie a testemunha-base ao verificador VM on-chain.
5. Acompanhe o relógio de cada equipe e cada transação. Registre tempo, extensões, inclusão e reorganização L1, calldata, gas, substituições, cauções, alegações paralelas e responsável pela resposta. A duração não é necessariamente uma contagem regressiva única; um resultado correto pode perder por atraso ou censura.
6. Mapeie a resolução às consequências. Determine alegações refutadas, equipe vencedora, distribuição de cauções e custos, exclusão de output inválido e reconstrução de outputs, provas ou saques dependentes. Caução confiscada é incentivo, não indenização integral de perdas no bridge.
7. Reconcilie finalidade e saques separadamente. Verifique resolução, atrasos de maturidade e pós-resolução, tipo respeitado, blacklist e pausa, prova de inclusão, recibo de finalização e finalidade L1. Arquive evidências e ensaie contestação, inclusão forçada, nova prova e saída de emergência.
## Exemplos calculados
- **Bisseção de traço.** Um traço didático contém `1,048,576 = 2^20 instructions`. Se cada rodada incontestada reduz o intervalo pela metade, `20 bisections` isolam uma instrução, pois `2^20 / 2^20 = 1`. Jogos reais podem dividir traços distintos, formar DAG ou exigir movimentos adicionais; não é uma contagem universal.
- **Relógios independentes.** Um jogo hipotético concede `84 hours` a cada equipe. O defensor consome `30 hours` e o desafiante `22 hours`, restando `54 hours` e `62 hours`. O tempo decorrido não é simplesmente `84 hours`: só o relógio aplicável avança, e extensões, atrasos de inclusão e alegações paralelas alteram o prazo.
- **Livro de caução e gas.** Sob regra explicitamente hipotética, uma raiz inválida tem caução de `2 ETH`. O vencedor depositou `0.5 ETH`, recupera o principal e recebe `1.4 ETH`, após gastar `0.08 ETH` em gas L1; `0.6 ETH` vai ao tesouro. O ganho líquido é `1.4 - 0.08 = 1.32 ETH`; os `0.5 ETH` devolvidos não são lucro, e `1.4 + 0.6 = 2 ETH`. Destinatários e comportamento de aproveitadores dependem do contrato.
- **Relógios de saque.** O saque é provado em `2026-08-01 12:00 UTC`, a maturidade é `7 days`, o jogo resolve em `2026-08-06 18:00 UTC` e o intervalo posterior é `1 day`. Os limites terminam em `2026-08-08 12:00 UTC` e `2026-08-07 18:00 UTC`; o primeiro instante que satisfaz ambos é `2026-08-08 12:00 UTC`. Com `20 minutes` de política de finalidade L1, a conclusão econômica ocorre em `2026-08-08 12:20 UTC`, sem pausa, blacklist, nova prova ou reorganização.
## Riscos
- Auditar L1, L2, implantação, tipo de jogo ou versão errados.
- Reconstruir de âncora ou head obsoleto, não canônico ou incorreto.
- Faltar lote, blob, preimage, testemunho ou configuração.
- Supor que um compromisso ou entrada disponível torna todos os dados disponíveis.
- Software do desafiante derivar outro traço por falha do cliente.
- Falhas no programa, VM, oráculo de preimages ou verificador de passo.
- Proponente, desafiante ou criação permissionados, indisponíveis ou capturados.
- Nenhum observador honesto detectar e abrir disputa no prazo.
- Censura, congestionamento, reorganização ou gas L1 impedirem uma ação.
- Interpretar mal relógios, extensões, profundidade ou inclusão.
- Atacar ou defender alegação, intervalo, posição ou instrução errados.
- Cauções ou capital de giro inviabilizarem a participação.
- Distribuição, aproveitadores ou incentivos divergirem das premissas.
- Jogos múltiplos, alegações duplicadas ou implementações conflitantes.
- Governança mudar tipo respeitado, verificador, limiar ou atraso.
- Pausa ou blacklist do Guardian bloquear saques válidos.
- Tratar resolução do jogo como finalidade imediata do saque.
- Provar contra jogo invalidado e não refazer a prova.
- Supor que rejeitar output inválido repara todo efeito posterior.
- Extrapolar o modelo de um rollup otimista para outro.
## Equívocos comuns
- Uma alegação otimista não contestada foi provada criptograficamente.
- Qualquer pessoa pode contestar toda implantação sem permissão, capital ou infraestrutura.
- A prova funciona mesmo sem os dados de derivação.
- Vencer finaliza todos os saques e reembolsa toda perda imediatamente.
- Sete dias, jogo binário e um observador honesto são constantes universais.
## Tópicos relacionados
- [Disponibilidade de dados](/pt-br/crypto/data-availability/)
- [Rollup otimista](/pt-br/crypto/optimistic-rollup/)
- [Prova de validade](/pt-br/crypto/validity-proof/)
## Fontes
- [Optimistic Rollups](https://ethereum.org/developers/docs/scaling/optimistic-rollups/) - Ethereum.org (acessado: 2026-08-12)
- [Fault Proof](https://specs.optimism.io/fault-proof/index.html) - OP Stack Specification (acessado: 2026-08-12)
- [Fault Dispute Game](https://specs.optimism.io/fault-proof/stage-one/fault-dispute-game.html) - OP Stack Specification (acessado: 2026-08-12)
- [Honest Challenger (Fault Dispute Game)](https://specs.optimism.io/fault-proof/stage-one/honest-challenger-fdg.html) - OP Stack Specification (acessado: 2026-08-12)
- [Bridge Integration](https://specs.optimism.io/fault-proof/stage-one/bridge-integration.html) - OP Stack Specification (acessado: 2026-08-12)
- [Optimism Portal](https://specs.optimism.io/fault-proof/stage-one/optimism-portal.html) - OP Stack Specification (acessado: 2026-08-12)
- [Data availability](https://ethereum.org/developers/docs/data-availability/) - Ethereum.org (acessado: 2026-08-12)
- [Arbitrum Nitro: A Second-Generation Optimistic Rollup](https://docs.arbitrum.io/nitro-whitepaper.pdf) - Offchain Labs (acessado: 2026-08-12)
Source: https://wiki.fcontext.com/pt-br/crypto/fraud-proof/index.mdx