Fraud Proof

O que é um Fraud Proof?

Um fraud proof é um mecanismo de blockchain que demonstra que uma transição de estado, um resultado de transação, um saque ou outro cálculo off-chain proposto está incorreto.

Os fraud proofs estão mais associados a optimistic rollups, que processam transações de criptomoedas fora de uma blockchain base e publicam dados compactados e compromissos de estado nela.

Um sistema otimista aceita temporariamente um resultado enviado, em vez de exigir uma prova criptográfica de validade para cada lote de transações.

Durante um período de contestação definido, um participante independente pode contestar um resultado incorreto apresentando evidências de que as regras do sistema não foram seguidas.

Se a contestação for bem-sucedida, a alegação inválida é rejeitada, o estado correto continua sendo válido e o participante desonesto ou equivocado pode perder uma garantia financeira.

A documentação da Ethereum sobre optimistic rollups explica que esses sistemas presumem que as transações off-chain são válidas, a menos que alguém as conteste por meio de um processo de prova de fraude.

Um fraud proof não necessariamente comprova que uma pessoa teve a intenção de cometer fraude, pois um resultado inválido também pode decorrer de um bug de software, erro de configuração, problema de hardware ou equívoco acidental de cálculo.

Por esse motivo, muitos desenvolvedores modernos de blockchain preferem o termo mais amplo fault proof, ou prova de falha.

Por que os Fraud Proofs são importantes em cripto?

Os fraud proofs permitem que sistemas blockchain tirem cálculos dispendiosos da camada base sem exigir que os usuários confiem completamente em um operador centralizado.

A blockchain base não precisa executar cada transação do rollup à medida que ela ocorre.

Ela só precisa armazenar informações suficientes para reconstruir o estado do rollup e resolver disputas quando alguém afirmar que um resultado inválido foi enviado.

Esse design otimista pode reduzir os custos de transação porque a verificação on-chain dispendiosa só é necessária principalmente quando os participantes discordam.

Os fraud proofs também apoiam a autocustódia ao oferecer aos usuários um caminho para contestar saques ou alegações de estado inválidos sem depender exclusivamente da organização que opera o rollup.

O mecanismo transforma a blockchain base em uma árbitra neutra que verifica evidências de acordo com as regras dos contratos inteligentes.

Um sistema bem projetado pode continuar seguro desde que pelo menos um participante honesto e capaz monitore a blockchain e consiga enviar uma contestação dentro do prazo.

Esse modelo de segurança costuma ser resumido como a premissa de uma parte honesta.

Como funciona um Fraud Proof?

Um sequenciador de rollup reúne as transações dos usuários, ordena-as, executa-as e cria uma nova versão do estado do rollup.

Em seguida, o rollup publica os dados das transações ou compromissos de dados e uma alegação sobre o estado resultante em sua blockchain de liquidação.

Essa alegação pode ser chamada de asserção, raiz de saída, raiz de estado, compromisso de estado ou checkpoint, conforme o protocolo.

O contrato de liquidação não presume imediatamente que a alegação seja definitivamente final.

Em vez disso, inicia um período de contestação durante o qual validadores ou contestadores podem reproduzir o cálculo de forma independente.

Um contestador honesto compara o resultado proposto com o resultado obtido ao executar as transações publicadas segundo as regras oficiais do rollup.

Se os dois resultados forem iguais, não será necessário um fraud proof, e a alegação poderá se tornar final após o encerramento do período de contestação.

Se os resultados forem diferentes, o contestador inicia uma disputa por meio do contrato de liquidação.

O processo de disputa restringe progressivamente o desacordo até que a blockchain de liquidação consiga verificar o cálculo exato responsável pelos resultados conflitantes.

Então, o contrato determina qual alegação segue as regras do protocolo e rejeita a outra.

Exemplo simples de Fraud Proof

Suponha que Alice comece com 10 tokens e Bob, com 2 tokens em um rollup.

Uma transação válida transfere 3 tokens de Alice para Bob.

O estado final correto atribui 7 tokens a Alice e 5 a Bob.

Suponha que o operador do rollup envie incorretamente um compromisso de estado indicando que Alice tem 6 tokens e Bob, 6 tokens.

Um validador independente reproduz a transação e calcula os saldos corretos.

O validador contesta o compromisso de estado do operador porque o resultado enviado não decorre do estado anterior nem da transação válida.

O fraud proof identifica a etapa de execução contestada e fornece as informações necessárias para que o contrato de liquidação verifique as regras da transferência.

O contrato confirma que apenas 3 tokens deveriam ter sido transferidos e rejeita o compromisso de estado incorreto.

O exemplo é simplificado, mas os sistemas reais de fraud proofs aplicam o mesmo princípio à execução complexa de contratos inteligentes, à contabilização de gas, às atualizações de armazenamento e aos compromissos criptográficos.

O que é um optimistic rollup?

Um optimistic rollup é um sistema de escalabilidade Layer 2 que executa transações de criptomoedas fora de uma blockchain base, usando essa blockchain para disponibilidade de dados, liquidação e resolução de disputas.

O termo “otimista” significa que os lotes de transações são considerados válidos por padrão, em vez de serem acompanhados imediatamente por uma prova de que cada cálculo está correto.

Em geral, os usuários recebem uma confirmação rápida dentro do rollup porque o sequenciador informa os resultados logo após processar as transações.

No entanto, a transferência do rollup de volta para a camada de liquidação pode exigir uma espera maior, pois a alegação de estado pertinente precisa resistir ao período de contestação.

Os optimistic rollups diferem das sidechains comuns porque sua segurança foi projetada para depender substancialmente da blockchain de liquidação, e não apenas de um grupo independente de validadores.

A documentação da Ethereum sobre escalabilidade diferencia os optimistic rollups, que executam cálculos contestados por meio de fraud proofs, dos zero-knowledge rollups, que enviam provas de validade.

O que é uma raiz de estado?

Uma raiz de estado é um compromisso criptográfico compacto que representa o estado completo de uma blockchain ou rollup em um ponto específico.

O estado pode incluir saldos de contas, código de contratos inteligentes, valores de armazenamento, nonces e outras informações necessárias para processar transações futuras.

Uma raiz de estado é muito menor do que o banco de dados subjacente completo.

Em geral, a alteração de até mesmo um único valor relevante muda o compromisso resultante.

Um proponente de rollup pode publicar uma raiz de estado sem colocar todo o estado diretamente no contrato de liquidação.

Outros participantes podem reconstruir o estado a partir dos dados de transação disponíveis e verificar se obtêm a mesma raiz.

Uma disputa de fraud proof costuma começar quando duas partes produzem raízes diferentes a partir do que deveria ser o mesmo estado inicial e a mesma sequência de transações.

O que é uma transição de estado?

Uma transição de estado é o processo de converter um estado antigo da blockchain em um novo estado executando uma ou mais transações válidas.

Uma fórmula simplificada é

.

A função de transição de estado contém as regras do protocolo que governam assinaturas, saldos, gas, execução de contratos, armazenamento e ordenação de transações.

Todos os participantes honestos que usem as mesmas entradas e a mesma versão do protocolo devem calcular o mesmo resultado.

Um fraud proof demonstra que um novo estado proposto não decorre corretamente do estado antigo e das entradas publicadas.

A execução determinística é essencial porque uma disputa não pode ser resolvida de forma confiável se computadores honestos puderem produzir respostas diferentes a partir de entradas idênticas.

O que é um período de contestação?

Um período de contestação é o intervalo durante o qual um resultado otimista pode ser contestado antes de se tornar final para fins de liquidação.

Muitos designs de optimistic rollup usam um período próximo de uma semana, embora a duração exata dependa do protocolo e possa mudar por meio de governança ou atualizações.

O período de espera dá aos validadores independentes tempo para baixar os dados, reproduzir a execução, detectar uma alegação inválida, obter fundos para taxas de transação ou garantias e enviar uma contestação.

Um período curto demais pode tornar a segurança muito dependente de monitoramento constante, infraestrutura rápida e acesso ininterrupto à blockchain de liquidação.

Um período longo demais pode reduzir a eficiência de capital e tornar inconvenientes os saques convencionais.

O guia da Ethereum sobre disponibilidade de dados explica que os optimistic rollups geralmente oferecem um prazo de contestação para que verificadores independentes possam conferir os dados publicados e contestar transições de estado incorretas.

Os usuários devem verificar as regras específicas de contestação e finalização de cada rede, em vez de presumir que todos os optimistic rollups usem exatamente sete dias.

Por que os saques demoram?

Um saque convencional de um optimistic rollup pode sofrer atrasos porque o contrato de liquidação precisa evitar liberar ativos com base em uma alegação de estado inválida.

Se uma alegação falsa pudesse se tornar final imediatamente, um invasor poderia inventar um saldo e sacar ativos bloqueados na camada de liquidação antes que alguém pudesse reagir.

O período de contestação dá aos validadores tempo para provar que o saque depende de um estado inválido do rollup.

Quando o compromisso de estado pertinente se torna final, o saque pode ser concluído de acordo com as regras da bridge do protocolo.

Os usuários podem obter acesso mais rápido por meio de acordos de liquidez com terceiros, mas essas opções introduzem taxas separadas, requisitos de liquidez, riscos de contratos inteligentes e premissas sobre contrapartes.

O guia da Ethereum sobre zero-knowledge rollups explica que os saques de optimistic rollups sofrem atrasos para permitir contestações com fraud proofs, enquanto sistemas de prova de validade podem finalizar as saídas após a verificação da prova.

O que é um Fraud Proof interativo?

Um fraud proof interativo usa um jogo de disputa em várias etapas entre partes que discordam sobre um cálculo longo.

Publicar e executar novamente um bloco inteiro do rollup diretamente na blockchain de liquidação poderia ser caro demais ou exceder os limites das transações.

Em vez disso, o proponente e o contestador se comprometem com traces de execução diferentes e restringem repetidamente o intervalo contestado.

Uma abordagem comum divide o trace em seções menores por meio de um processo chamado bisseção.

Cada rodada identifica qual metade contém a primeira divergência.

O processo continua até que a disputa envolva uma instrução de máquina ou outra operação pequena que o contrato de liquidação possa verificar diretamente.

A blockchain de liquidação não precisa reproduzir todas as etapas, pois verifica apenas os compromissos, as jogadas da disputa e a instrução final contestada.

A documentação oficial sobre um design interativo de disputa atual explica como uma disputa pode ser restringida até chegar a uma prova de uma única etapa, verificada pela blockchain principal.

O que é uma prova de uma única etapa?

Uma prova de uma única etapa fornece informações suficientes para que um contrato de liquidação verifique uma instrução contestada no trace de execução de um rollup.

A prova identifica o estado da máquina antes da instrução, a própria instrução, os dados de entrada necessários e o estado posterior alegado.

O contrato de liquidação aplica as regras da instrução e calcula o próximo estado correto.

Se o resultado corresponder à alegação do contestador, e não à do proponente, o contestador vence a disputa.

A verificação de uma única etapa permite impor cálculos off-chain extensos sem exigir que a blockchain de liquidação execute rotineiramente o programa completo do rollup.

A máquina virtual usada na execução da prova precisa ser determinística e representar com precisão as regras de consenso do rollup.

O que é um Fraud Proof não interativo?

Um fraud proof não interativo tenta fornecer todas as evidências necessárias para estabelecer que uma transição é inválida em um único envio ou processo limitado de verificação.

Esse design pode reduzir a necessidade de respostas repetidas entre o proponente e o contestador.

Ele pode exigir que a prova contenha mais dados ou use um método especializado para isolar o cálculo incorreto.

Os sistemas interativos podem reduzir o trabalho on-chain restringindo as disputas ao longo de várias rodadas, enquanto os sistemas não interativos podem acelerar a resolução e reduzir a dependência da continuidade durante a disputa.

O melhor design depende da complexidade da execução, dos custos da camada de liquidação, do tamanho da prova, da segurança da implementação e dos tipos de falha que o protocolo precisa tratar.

Fraud Proof vs. Fault Proof

Os termos fraud proof e fault proof costumam descrever o mesmo mecanismo geral de disputa otimista.

Historicamente, o termo fraud proof era comum por descrever evidências usadas para contestar um comportamento desonesto.

O termo fault proof é mais preciso porque o mecanismo verifica se um resultado está errado, em vez de determinar a intenção do operador.

Uma saída incorreta pode resultar de manipulação maliciosa, software desatualizado, configuração incorreta, banco de dados corrompido ou erro comum de programação.

A documentação atual dos protocolos usa cada vez mais fault proof ao descrever sistemas de disputa em produção.

A documentação oficial do sistema de fault proofs descreve uma arquitetura modular que inclui um programa de fault proof, uma máquina virtual de fault proof e um protocolo de jogos de disputa.

Fraud Proof vs. prova de validade

Um fraud proof demonstra que um resultado enviado está errado depois que alguém o contesta.

Uma prova de validade demonstra que uma transição de estado enviada está correta antes de o contrato de liquidação aceitá-la.

Em geral, optimistic rollups publicam alegações de estado sem provas de validade e dependem de um período de contestação.

Os validity rollups geram provas criptográficas, muitas vezes usando tecnologia de zero-knowledge proof, para lotes de cálculos off-chain.

Um verificador de provas de validade pode rejeitar um lote incorreto imediatamente, pois um invasor não deveria conseguir criar uma prova válida para uma transição inválida.

Um sistema de fraud proofs pode exigir menos cálculos durante a operação normal porque não há necessidade de calcular uma disputa quando todas as alegações estão corretas.

Um sistema de provas de validade pode oferecer liquidação mais rápida após a geração da prova, mas talvez exija infraestrutura de geração complexa e criptografia especializada.

Nenhum dos dois designs é automaticamente superior, pois a segurança também depende da disponibilidade de dados, da qualidade da implementação, dos poderes de governança, dos controles de atualização e da camada de liquidação.

Fraud Proof vs. Zero-Knowledge Proof

Uma zero-knowledge proof permite que uma parte prove que uma afirmação é verdadeira sem revelar todas as entradas privadas usadas para comprová-la.

Muitos sistemas de validade em blockchain usam provas sucintas de zero-knowledge, mesmo quando os dados das transações continuam públicos para a reconstrução do estado.

Um fraud proof costuma ser reativo, pois é criado depois que um resultado incorreto é proposto.

Uma prova de validade de zero-knowledge costuma ser proativa, pois acompanha ou antecede a aceitação do novo estado.

Os fraud proofs dependem da possibilidade de uma parte honesta perceber e contestar uma falha.

As provas de validade dependem da solidez criptográfica e da implementação correta do verificador.

Arquiteturas futuras de rollup podem combinar fault proofs, provas de validade, atestações e várias implementações independentes para reduzir a dependência de um único sistema.

Fraud Proof vs. Merkle Proof

Uma Merkle proof demonstra que determinado item pertence a um conjunto de dados representado por uma raiz de Merkle.

Por exemplo, ela pode demonstrar que um saldo de conta, uma transação ou uma mensagem de saque está incluído em uma árvore comprometida.

Um fraud proof demonstra que um cálculo ou uma transição de estado alegada é inválida.

Os fraud proofs muitas vezes contêm Merkle proofs para que o contrato de liquidação possa acessar apenas as pequenas partes do estado necessárias para verificar a etapa contestada.

Uma Merkle proof pode comprovar inclusão sem provar que a transação incluída foi executada corretamente.

Portanto, os dois tipos de prova têm finalidades distintas, mas costumam funcionar em conjunto.

O papel da disponibilidade de dados

Os fraud proofs não conseguem proteger um rollup quando os contestadores não têm acesso aos dados necessários para reconstruir o estado e identificar uma execução incorreta.

Caso contrário, um operador malicioso poderia publicar um compromisso de estado enquanto oculta as transações que o originaram.

Os validadores independentes saberiam que não podem reproduzir o resultado, mas talvez não consigam criar a prova exigida de uma falha específica.

Os optimistic rollups lidam com esse problema publicando dados de transação compactados ou compromissos de dados reconhecidos pelo protocolo por meio da camada de liquidação.

Os rollups da Ethereum podem publicar dados por meio de calldata em transações comuns ou de transações com blobs projetadas para dados de rollup.

A especificação EIP-4844 introduziu transações com blobs que permitem aos rollups publicar dados temporários de maneira mais econômica do que o calldata permanente de execução.

Como os dados de blobs são mantidos pelo protocolo por um período limitado, os sistemas de monitoramento precisam recuperar e preservar as informações necessárias durante o período de contestação.

Portanto, a disponibilidade de dados é uma parte fundamental da segurança dos fraud proofs, e não um recurso opcional separado.

O papel da blockchain de liquidação

A blockchain de liquidação armazena compromissos do rollup, recebe transações de disputa, administra as garantias dos participantes e executa a lógica final de verificação.

Ela atua como árbitra neutra porque suas regras de consenso determinam quais movimentos e provas de disputa são válidos.

O rollup herda parte de sua segurança da finalização, resistência à censura, execução de contratos inteligentes e disponibilidade de dados da camada de liquidação.

Se a blockchain de liquidação deixar de finalizar blocos, as alegações e os saques do rollup também podem parar de avançar.

Se os invasores conseguirem censurar todas as contestações honestas durante todo o período de disputa, pode ser difícil impedir a finalização de uma alegação inválida.

Assim, a segurança dos fraud proofs depende tanto do código do rollup quanto da disponibilidade da blockchain de liquidação e de sua resistência à censura prolongada.

O papel do sequenciador

Um sequenciador recebe as transações dos usuários, escolhe sua ordem, executa os blocos do rollup e publica lotes ou compromissos de transações.

Um sequenciador centralizado pode oferecer confirmações rápidas, mas também pode atrasar, reordenar ou censurar transações.

Os fraud proofs protegem contra execução inválida, mas não impedem automaticamente todas as formas de censura de transações ou de ordenação prejudicial.

Um sequenciador pode publicar um estado válido, conforme as regras do protocolo, e ainda assim excluir temporariamente a transação de um usuário.

Os sistemas de rollup podem oferecer caminhos de inclusão forçada que permitem aos usuários enviar transações pela camada de liquidação quando o sequenciador se recusa a incluí-las.

Os usuários devem diferenciar a correção da execução, tratada pelos fraud proofs, da justiça na ordenação e da continuidade operacional, que exigem mecanismos adicionais.

O papel de um contestador

Um contestador é um participante ou serviço automatizado que monitora os estados propostos pelo rollup e contesta alegações inválidas.

O contestador executa um software de nó compatível e reproduz a execução do rollup com base nos dados da camada de liquidação.

Ele precisa permanecer online, acompanhar as atualizações do protocolo, manter as informações históricas necessárias e enviar transações antes dos prazos pertinentes.

Um contestador pode precisar de criptomoedas para pagar gas na camada de liquidação e fornecer garantias financeiras.

O software atual dos contestadores pode monitorar disputas, defender propostas válidas, contestar propostas inválidas e reivindicar garantias após uma vitória.

A documentação oficial para contestadores descreve um serviço de produção que depende de um nó de rollup sincronizado e de um provedor determinístico de traces.

A participação permissionless tem maior significado quando partes tecnicamente independentes podem operar contestadores sem aprovação de uma organização central.

Por que são usadas garantias?

Uma garantia é uma quantia em criptomoeda bloqueada por um participante ao propor uma alegação ou fazer determinados movimentos em uma disputa.

As garantias desestimulam os invasores a criar alegações falsas sem limite ou a obrigar validadores honestos a gastar recursos sem consequências financeiras.

Um participante que apoie uma alegação incorreta pode perder parte ou a totalidade da garantia correspondente.

Um contestador bem-sucedido pode recuperar sua garantia e receber uma recompensa econômica, conforme o protocolo.

O valor das garantias precisa ser suficiente para desestimular abusos, sem ser tão alto que apenas organizações ricas possam participar.

Garantias excessivamente altas podem tornar, na prática, inacessível um sistema de fraud proofs teoricamente permissionless.

Garantias excessivamente baixas podem incentivar spam, ataques de obstrução e atrasos maliciosos.

O design das garantias precisa considerar taxas da camada de liquidação, volatilidade dos ativos, duração das disputas, custo de oportunidade do capital e valor em risco.

Fraud proofs permissionless vs. permissionados

Um sistema permissionless de fraud proofs permite que qualquer participante que atenda aos requisitos técnicos e econômicos públicos envie ou conteste uma alegação de estado.

Um sistema permissionado restringe as propostas, as contestações ou ambas às ações de endereços ou organizações aprovados.

A validação permissionada pode reduzir spam e incertezas operacionais durante as primeiras etapas do desenvolvimento.

Ela também cria premissas de confiança, pois os usuários dependem de que os validadores aprovados permaneçam honestos, disponíveis e independentes.

Os sistemas permissionless ampliam a abertura, mas exigem defesas robustas contra ataques de obstrução, atrasos, manipulação de garantias e exploração de software.

Uma rede pode oferecer jogos de disputa permissionless e, ao mesmo tempo, manter um conselho de emergência ou uma autoridade de atualização capaz de pausar ou substituir partes do sistema.

Os usuários devem examinar o modelo de segurança completo, em vez de presumir que um caminho permissionless de contestação elimina todos os poderes administrativos.

Desenvolvimentos atuais dos Fraud Proofs

Em julho de 2026, os sistemas de fault proof em produção continuam evoluindo com novos clientes, máquinas virtuais atualizadas, protocolos de disputa aprimorados e participação permissionless mais ampla.

A documentação oficial do OP Stack descreve contestações permissionless e uma transição, em 2026, para um cliente de fault proof mais recente. Isso mostra que os operadores de contestadores precisam acompanhar os softwares atuais e os estados iniciais absolutos.

O aviso oficial de 2026 sobre a migração do cliente de fault proof explica que o suporte ao software de provas antigo terminou e que os operadores da rede precisam migrar para a implementação substituta.

A documentação oficial da Arbitrum descreve o BoLD como um design de disputa com prazo limitado que oferece validação permissionless e limita a capacidade de participantes maliciosos de prolongar indefinidamente as disputas.

A visão geral do BoLD de 2026 explica como os fraud proofs interativos podem permitir contestações abertas e, ao mesmo tempo, limitar a duração das disputas.

Esses avanços mostram que os fraud proofs são sistemas de segurança ativos em produção, e não apenas ideias teóricas sobre blockchain.

Também mostram que os sistemas de prova exigem auditorias contínuas, manutenção de clientes, coordenação de atualizações, monitoramento e resposta a incidentes.

Fraud Proofs e atualizações de software

Um programa de fault proof precisa executar as mesmas regras de consenso da versão do rollup cujo estado está sendo contestado.

Uma atualização de protocolo pode alterar a execução de transações, os custos de gas, os precompilados, as regras de blocos, os contratos do sistema ou a interpretação dos dados.

Um software de contestador que use regras desatualizadas pode classificar incorretamente uma alegação válida como inválida ou deixar de contestar uma alegação realmente inválida.

Os sistemas de prova costumam usar um estado inicial absoluto que se compromete com a condição de partida da máquina virtual de prova.

A alteração do programa de prova ou das regras de consenso pode exigir um novo estado inicial e contratos on-chain atualizados.

Os operadores precisam coordenar as atualizações cuidadosamente para que disputas antigas e novas sejam resolvidas de acordo com as regras corretas.

Essa complexidade é uma das razões pelas quais várias implementações independentes de prova são consideradas valiosas para a segurança de longo prazo.

O que é um ataque de atraso?

Um ataque de atraso tenta prolongar a resolução de uma disputa ou impedir a finalização de um estado válido sem provar com sucesso que o estado é inválido.

Um invasor pode criar alegações conflitantes, forçar rodadas repetidas de contestação, explorar regras de tempo ou bloquear o capital de participantes honestos.

Designs interativos mais antigos podiam permitir que invasores iniciassem disputas sequenciais que prolongavam repetidamente os atrasos nos saques.

Os designs de disputa com prazo limitado procuram garantir que muitas alegações maliciosas possam ser resolvidas dentro de um período máximo previsível.

As garantias financeiras tornam os ataques de atraso dispendiosos, mas não eliminam a necessidade de regras sólidas para prazos e jogos de disputa.

Um sistema precisa proteger a segurança, garantindo que alegações inválidas não sejam finalizadas, e também a continuidade operacional, garantindo que alegações válidas acabem sendo finalizadas.

Segurança vs. continuidade operacional

Segurança significa que o sistema de fraud proofs não aceita um estado inválido nem permite um saque não autorizado.

Continuidade operacional significa que transações, alegações de estado e saques honestos avançam até a conclusão.

Um sistema pode preservar a segurança pausando todos os saques durante um período de incerteza, mas essa medida prejudica a continuidade operacional.

Um sistema pode melhorar a continuidade operacional finalizando alegações rapidamente, mas um período de contestação curto demais pode enfraquecer a segurança.

Controles de emergência, tempos limite para disputas, garantias, períodos de contestação e regras de permissão equilibram esses dois objetivos.

Ao avaliar um rollup, os usuários devem perguntar tanto se os fundos podem ser roubados quanto se podem ficar indisponíveis por muito tempo.

Principais premissas de segurança dos Fraud Proofs

Em geral, um rollup com fraud proofs pressupõe que pelo menos uma parte honesta consiga reconstruir o estado do rollup e contestar alegações inválidas.

Os dados de transação necessários devem permanecer disponíveis por tempo suficiente para que essa parte faça a verificação.

A blockchain de liquidação precisa continuar processando transações e não pode censurar todas as contestações honestas durante todo o período de disputa.

A função de transição de estado do rollup e a máquina virtual de prova precisam implementar corretamente as regras pretendidas.

Os contratos de disputa on-chain precisam avaliar corretamente jogadas, prazos, garantias, compromissos e provas finais.

Os contestadores honestos precisam usar software atual, recursos computacionais suficientes, fontes de dados confiáveis e fundos adequados para pagar gas e garantias.

Chaves de atualização, guardians, conselhos de segurança e contratos de governança não devem abusar de poderes que permitam substituir ou contornar o sistema de provas.

Um único contestador honesto pode proteger todos?

Em princípio, um único contestador honesto pode impedir a finalização de uma alegação de estado inválida quando o protocolo é permissionless e todas as premissas necessárias se confirmam.

O contestador não precisa do apoio da maioria dos usuários do rollup, porque o contrato de liquidação decide a disputa de acordo com regras objetivas de execução.

No entanto, a parte honesta precisa detectar a falha, ter os dados necessários, permanecer online, poder arcar com a participação e não sofrer censura.

Um sistema que, tecnicamente, precisa de apenas um contestador é mais robusto quando vários contestadores independentes usam infraestruturas e implementações de software diferentes.

A diversidade reduz o risco de que um único bug, interrupção, restrição legal ou falha de um provedor de nuvem desative todos os sistemas de monitoramento ao mesmo tempo.

Os Fraud Proofs conseguem impedir todos os ataques a rollups?

Os fraud proofs podem rejeitar transições de estado inválidas, mas não resolvem todos os problemas de segurança que afetam um rollup.

Eles não impedem automaticamente a censura do sequenciador, o roubo de chaves de usuários, contratos maliciosos de aplicativos, phishing, manipulação de oráculos ou ataques de governança.

Eles podem não proteger os usuários quando os dados ficam armazenados fora da camada de liquidação, sujeitos a premissas mais fracas de disponibilidade.

Também não ajudam quando o próprio sistema de provas contém um bug grave compartilhado que leva participantes honestos e desonestos a calcular o mesmo resultado incorreto.

Um rollup seguro exige fraud proofs, além de boa disponibilidade de dados, contratos de bridge auditados, procedimentos seguros de atualização, nós confiáveis e governança transparente.

Fraud Proofs no Plasma

Os sistemas Plasma usam uma blockchain principal para resolver disputas relacionadas à atividade em uma cadeia secundária.

Os usuários podem enviar fraud proofs quando um operador tenta finalizar uma transação ou um estado inválido.

Os designs tradicionais de Plasma geralmente mantêm grande parte dos dados de transação fora da blockchain principal.

Essa estrutura cria um problema de retenção de dados, pois os usuários podem não conseguir construir um fraud proof quando o operador se recusa a fornecer as informações necessárias.

A documentação da Ethereum sobre Plasma explica que os rollups melhoram esse modelo de segurança ao publicar dados de transação por meio da camada de liquidação.

Os fraud proofs aparecem tanto no Plasma quanto nos optimistic rollups, mas as garantias de disponibilidade de dados são diferentes.

Fraud Proofs em canais de estado

Os canais de estado permitem que um grupo definido de participantes troque atualizações de estado assinadas fora da blockchain.

Normalmente, os participantes usam a blockchain apenas para abrir o canal, liquidar o estado final ou resolver uma disputa.

Um participante desonesto pode tentar fechar o canal usando um estado antigo que lhe atribua um saldo mais favorável.

Durante o período de contestação, o participante honesto pode responder apresentando um estado mais recente, assinado corretamente.

Essa evidência funciona como um fraud proof porque demonstra que a liquidação tentada está desatualizada ou é inválida.

O guia da Ethereum sobre canais de estado explica como a arbitragem de disputas protege os usuários quando um estado inválido ou desatualizado é enviado.

Como os Fraud Proofs afetam os usuários de cripto

A maioria dos usuários de rollup não envia fraud proofs pessoalmente, pois validadores especializados e serviços de monitoramento fazem verificações contínuas.

Ainda assim, os usuários dependem do mecanismo sempre que mantêm ativos, interagem com aplicativos ou sacam por meio da bridge canônica de um optimistic rollup.

Um usuário pode ver uma transação confirmada rapidamente no rollup enquanto a finalização na camada de liquidação ainda está pendente.

Uma contestação bem-sucedida pode reverter resultados ainda não finalizados que se baseiem em uma alegação de estado inválida.

As carteiras e os aplicativos devem comunicar a diferença entre confirmação do sequenciador, confirmação da camada de liquidação e finalização completa do saque.

Os usuários também devem entender se os fraud proofs da rede estão ativos, são permissionless, podem ser atualizados ou dependem de controles administrativos de emergência.

Como os desenvolvedores devem projetar sistemas com Fraud Proofs

Os desenvolvedores de rollups precisam garantir que todas as operações relevantes para o consenso possam ser reproduzidas de forma determinística no ambiente de prova.

Devem evitar dependências de horário local, comportamento aleatório não documentado do sistema operacional, serviços externos sem documentação ou resultados específicos de hardware.

O código de prova, o código do nó e os contratos de verificação on-chain precisam concordar quanto à semântica das instruções e aos formatos dos dados.

Os desenvolvedores devem testar saídas inválidas, respostas atrasadas, alegações conflitantes, dados ausentes, esgotamento das garantias e atualizações do protocolo.

Devem fornecer procedimentos claros para operar contestadores e verificar os estados iniciais e endereços de contratos necessários.

As auditorias de segurança devem examinar tanto o caminho normal de execução do rollup quanto o caminho de disputa, usado raramente.

Um sistema de disputa que nunca foi testado em condições adversas realistas pode falhar quando finalmente for necessário.

Como avaliar um sistema de Fraud Proof

Comece verificando se a rede realmente tem um sistema ativo de fraud proofs, em vez de apenas um roteiro ou design planejado.

Confira se qualquer pessoa pode enviar contestações ou se a participação é controlada por uma lista de permissões.

Identifique o período de contestação, o atraso de saque, os requisitos de garantia, os prazos de disputa e o tempo máximo de resolução esperado.

Descubra onde os dados das transações são publicados e se os usuários podem reconstruir o estado do rollup de forma independente.

Verifique se guardians de emergência, conselhos de segurança, administradores ou contratos de governança podem substituir resultados finalizados.

Procure vários operadores de contestadores, software público de nós, compilações reproduzíveis, auditorias, divulgação de vulnerabilidades e programas de recompensa por bugs.

Confirme como o sistema de provas trata atualizações do protocolo e disputas iniciadas em uma versão anterior do software.

Uma descrição sólida de segurança deve explicar as limitações e as premissas de confiança, em vez de simplesmente afirmar que o rollup herda toda a segurança da camada base.

Equívocos comuns sobre Fraud Proofs

Um equívoco comum é pensar que cada transação de rollup vem acompanhada de um fraud proof.

Em geral, os fraud proofs são produzidos apenas quando alguém contesta um resultado discutido.

Outro equívoco é achar que um fraud proof comprova intenção criminosa ou desonesta.

O mecanismo comprova que um cálculo ou uma alegação está incorreto; a intenção jurídica é uma questão separada.

Alguns usuários acreditam que um atraso de uma semana no saque significa que a própria transação do rollup demora uma semana para ser executada.

A transação do rollup pode ser executada em segundos, enquanto o período mais longo se aplica à liquidação e à segurança do saque canônico.

Outro erro é presumir que fraud proofs permissionless eliminam todos os controles centralizados.

Um rollup pode permitir contestações abertas e, ainda assim, manter sequenciamento centralizado, chaves de atualização, guardians ou poderes de pausa de emergência.

Riscos dos Fraud Proofs

O risco de implementação surge quando o programa de prova, a máquina virtual ou os contratos inteligentes contêm bugs.

O risco de disponibilidade de dados surge quando os contestadores não conseguem obter as informações necessárias para reconstruir o estado contestado.

O risco de censura surge quando uma transação de fraud proof honesta não consegue chegar à blockchain de liquidação antes do prazo.

O risco para a continuidade operacional surge quando alegações maliciosas ou falhas de software atrasam saques válidos.

O risco econômico surge quando o preço do gas ou os requisitos de garantia tornam as contestações caras demais.

O risco de atualização surge quando nós, programas de prova, contratos e estados iniciais não seguem a mesma versão do protocolo.

O risco de governança surge quando partes privilegiadas podem pausar, substituir ou contornar o sistema de disputa.

O risco operacional surge quando todos os contestadores dependem do mesmo provedor de nuvem, base de código, banco de dados ou serviço de monitoramento.

Perguntas frequentes

O que é um fraud proof, em termos simples?

Um fraud proof é uma evidência de que um resultado proposto para uma blockchain ou um rollup foi calculado incorretamente.

Por que os fraud proofs são usados em cripto?

Eles permitem que cálculos off-chain escalem uma blockchain, dando aos participantes independentes uma forma de rejeitar resultados inválidos.

Qual é a diferença entre fraud proof e fault proof?

Em geral, os termos descrevem o mesmo mecanismo, mas fault proof evita sugerir que todo resultado incorreto tenha sido fraudulento de propósito.

Quais sistemas cripto usam fraud proofs?

Os fraud proofs são usados principalmente em optimistic rollups, embora mecanismos de disputa relacionados também apareçam em sistemas Plasma e canais de estado.

Cada transação de um optimistic rollup gera um fraud proof?

Não. Normalmente, os fraud proofs só são gerados quando um participante contesta uma alegação de estado incorreta.

Quem pode enviar um fraud proof?

Qualquer pessoa pode enviar um em um sistema totalmente permissionless, enquanto sistemas permissionados restringem as contestações a participantes aprovados.

O que é um contestador?

Um contestador é um participante ou serviço automatizado que verifica as alegações de estado do rollup e contesta aquelas que não seguem as regras do protocolo.

O que é um período de contestação?

É o período durante o qual um estado otimista proposto pode ser contestado antes de se tornar final.

Quanto dura o período de contestação de um fraud proof?

A duração depende do protocolo, embora períodos próximos de uma semana sejam comuns em optimistic rollups em produção.

Por que os saques de optimistic rollups demoram vários dias?

O atraso dá aos contestadores tempo para impedir saques baseados em estados inválidos ou fabricados do rollup.

Um fraud proof pode reverter uma transação?

Ele pode invalidar uma alegação de estado ainda não finalizada e os resultados baseados nela, conforme as regras de disputa e recuperação do rollup.

O que é um fraud proof interativo?

Um fraud proof interativo usa várias rodadas de disputa para restringir um cálculo longo até chegar a uma pequena etapa que possa ser verificada on-chain.

O que é bisseção em um fraud proof?

A bisseção divide repetidamente um trace de execução para que as partes em disputa isolem o primeiro ponto em que seus resultados diferem.

O que é uma prova de uma única etapa?

Uma prova de uma única etapa permite que o contrato de liquidação verifique uma instrução de máquina contestada e determine qual participante a calculou corretamente.

O que é uma raiz de saída?

Uma raiz de saída é um compromisso criptográfico com o estado de um rollup e informações relacionadas em determinado bloco.

O que é a premissa de uma parte honesta?

É a premissa de que pelo menos um participante capaz detectará e contestará um estado inválido antes do prazo.

Um sistema de fraud proofs precisa de muitos validadores?

Em teoria, um único contestador honesto pode ser suficiente, mas vários contestadores independentes oferecem maior resiliência operacional.

Por que a disponibilidade de dados é necessária?

Os contestadores precisam dos dados das transações para reconstruir o estado do rollup e demonstrar exatamente onde ocorreu uma transição incorreta.

Os fraud proofs podem funcionar quando os dados das transações estão ocultos?

Eles podem falhar quando os dados ocultos são necessários para reproduzir a execução e o protocolo não oferece uma prova separada de disponibilidade dos dados.

Qual é a diferença entre um fraud proof e uma prova de validade?

Um fraud proof demonstra que um resultado está errado após uma contestação, enquanto uma prova de validade demonstra que o resultado está correto antes de ser aceito.

Um fraud proof é uma zero-knowledge proof?

Não. Em geral, um fraud proof é um mecanismo otimista de disputa, embora sistemas avançados possam combinar fault proofs com tecnologia de zero-knowledge.

Uma Merkle proof é o mesmo que um fraud proof?

Não. Uma Merkle proof comprova a inclusão em um conjunto de dados comprometido, enquanto um fraud proof demonstra um cálculo ou uma transição de estado incorretos.

O que acontece quando um fraud proof é bem-sucedido?

A alegação inválida é rejeitada, o estado correto é preservado e o participante perdedor pode perder uma garantia.

O que acontece quando uma contestação falha?

A alegação contestada pode continuar rumo à finalização, e o contestador malsucedido pode perder parte dos fundos dados como garantia.

Por que são exigidas garantias?

As garantias desestimulam alegações falsas, spam e disputas desnecessárias ao tornar financeiramente custosa a participação desonesta ou descuidada.

Os fraud proofs conseguem impedir a censura do sequenciador?

Não. Eles verificam a correção da execução, enquanto a resistência à censura geralmente exige mecanismos de inclusão forçada e outros recursos do protocolo.

Os fraud proofs podem impedir ataques a contratos inteligentes?

Não. Uma transação maliciosa ou vulnerável de um aplicativo, executada corretamente, ainda pode ser válida segundo as regras de transição de estado do rollup.

Um contrato de fraud proof pode ter um bug?

Sim. Programas de prova, máquinas virtuais, contratos de disputa e softwares de contestadores podem conter vulnerabilidades de implementação.

O que é um ataque de atraso?

Um ataque de atraso tenta prolongar a resolução de uma disputa ou impedir uma finalização válida sem provar com sucesso que um estado está incorreto.

O que é uma disputa com prazo limitado?

É uma disputa projetada para ser resolvida dentro de um período máximo previsível, mesmo que sejam enviadas muitas alegações maliciosas.

Todos os sistemas de fraud proofs são permissionless?

Não. Algumas redes restringem validadores ou contestadores, enquanto outras permitem a participação pública sujeita a requisitos técnicos e de garantia.

Um sistema permissionless de fraud proofs ainda pode ter administradores?

Sim. Guardians de emergência, autoridades de atualização, órgãos de governança ou conselhos de segurança podem manter poderes importantes.

Os usuários precisam executar software de contestador?

Em geral, usuários comuns dependem de validadores independentes, embora executar software de verificação possa reduzir a dependência de outros participantes.

O que os usuários devem verificar antes de usar um optimistic rollup?

Os usuários devem verificar se os fraud proofs estão ativos, quem pode contestar, onde os dados ficam armazenados, quanto tempo os saques demoram e quais partes têm poderes de emergência.

Conclusão

Um fraud proof é um mecanismo de disputa que demonstra que um lote de transações de criptomoedas, uma transição de estado, uma raiz de saída ou uma alegação de saque foi calculado incorretamente.

Ele é um componente central da segurança dos optimistic rollups, pois esses sistemas aceitam temporariamente resultados off-chain sem exigir uma prova de validade imediata.

Contestadores independentes reproduzem a execução e contestam alegações incorretas durante um período definido.

Jogos de disputa interativos podem restringir milhões de etapas de cálculo até chegar a uma instrução que a blockchain de liquidação verifica diretamente.

A disponibilidade de dados é essencial, pois os contestadores não podem provar uma falha sem acesso às transações subjacentes a um compromisso de estado.

Garantias financeiras desestimulam alegações falsas e compensam parte do custo de defesa do sistema.

Fraud proofs permissionless reduzem a dependência de validadores aprovados, mas não eliminam todas as premissas de confiança relacionadas a governança, atualizações, sequenciamento ou operação.

Os fraud proofs diferem das provas de validade porque rejeitam resultados incorretos após uma contestação, em vez de comprovar que cada resultado está correto antes da aceitação.

Em 2026, os sistemas de fault proof em produção continuam evoluindo com clientes de prova atualizados, protocolos de disputa com prazo limitado e participação permissionless mais ampla.

Compreender os fraud proofs ajuda os usuários de cripto a avaliar a segurança dos rollups, os atrasos nos saques, a disponibilidade de dados, as premissas sobre contestadores e os limites reais da escalabilidade otimista de blockchains.