Ir para o conteúdo
Financial Context Wiki

Prova de falha (prova de fraude)

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.

Atualizado

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.

1
Sequência

O sequenciador ordena transações L2 e publica dados de transação ou compromissos.

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

Fontes

Navegação

Pesquisar na wiki...