Como é bem conhecido, as provas de fraude são uma solução técnica amplamente utilizada no espaço blockchain. Elas originaram-se na comunidade Ethereum e foram adotadas por soluções conhecidas de camada 2 do Ethereum, como Arbitrum e Optimism. Após o surgimento do ecossistema Bitcoin em 2023, Robin Linus propôs uma solução chamada BitVM, que, com base em tecnologias Bitcoin existentes como Taproot, concentra-se em provas de fraude e fornece um novo modelo de segurança para a camada 2 do Bitcoin ou pontes.

BitVM lançou várias versões teóricas, desde a BitVM0 inicial, que utilizava circuitos de portas lógicas como primitivas, até versões posteriores como a BitVM2, que se concentrou em Provas de Fraude ZK e circuitos de verificação Groth16. Os caminhos de implementação técnica relacionados ao BitVM têm evoluído e amadurecido, atraindo a atenção de muitos profissionais da indústria. Projetos como Bitlayer, Citrea, BOB, Fiamma e Goat Network todos utilizam o BitVM como uma de suas tecnologias principais, implementando diferentes versões com base nessa fundação.

Dada a escassez e complexidade das explicações publicamente disponíveis sobre o BitVM, lançamos uma série de artigos com o objetivo de popularizar o conhecimento sobre o BitVM. Considerando a conexão profundamente enraizada entre o BitVM e as provas de fraude, este artigo se concentrará em provas de fraude e Provas de Fraude ZK, usando linguagem simples e compreensível para explicar esses conceitos.

(Mecanismo de prova de fraude interativa do Princípio do Otimismo)

OutputRoot e StateRoot

Optimism é um projeto bem conhecido de Rollup otimista, e sua infraestrutura é composta por um sequenciador (com módulos principais incluindo op-node, op-geth, op-batcher e op-proposer) e contratos inteligentes na cadeia Ethereum.

Após o sequenciador processar um lote de dados de transação, esses dados DA serão enviados para o Ethereum. Contanto que você seja capaz de executar um cliente de nó de Optimism, você pode baixar os dados enviados pelo sequenciador para sua máquina local. Você pode então executar essas transações localmente e calcular o hash do conjunto de estado atual do Optimism (incluindo, mas não se limitando ao saldo atual de cada conta, etc.).

Se o sequenciador enviar um hash de conjunto de estado incorreto para o Ethereum, o hash de conjunto de estado que você calcular localmente será diferente. Nesse caso, você pode apresentar um desafio através do sistema à prova de fraude. Com base no julgamento, o sistema aplicará restrições ou penalidades ao sequenciador ou não tomará nenhuma ação.

Ao mencionar o termo “conjunto de estados”, blockchains baseados em EVM comumente usam uma estrutura de dados semelhante a uma árvore de Merkle para registrar o conjunto de estados, chamada de World State Trie. Após a execução de uma transação, o estado de certas contas mudará e o World State Trie também mudará, resultando em uma alteração em seu hash final. Ethereum se refere ao hash final do World State Trie como o StateRoot, que representa as mudanças no conjunto de estados.

O diagrama a seguir ilustra a estrutura do stateRoot do Ethereum. Como podemos ver, os saldos das diferentes contas, o código hash associado às contas de contratos inteligentes e outros dados são todos agregados na World State Trie, a partir da qual o stateRoot é calculado.

O sistema de contas e estrutura de dados do Optimism são geralmente consistentes com os do Ethereum, também utilizando o campo StateRoot para representar as alterações no conjunto de estados. O sequenciador OP faz upload periodicamente de um campo-chave chamado OutputRoot para o Ethereum, que é calculado com base no StateRoot e em outros dois campos.

Voltando à pergunta inicial, quando você executa o cliente do nó OP e calcula o StateRoot e o OutputRoot atual localmente, se descobrir que os resultados calculados não correspondem aos enviados pelo sequenciador OP, você pode iniciar uma prova de fraude. Então, qual é o mecanismo específico por trás disso? A seguir, introduziremos sequencialmente a verificação de estado da máquina virtual MIPS e provas de fraude interativas.

MIPS Máquina Virtual e Árvore Merkle de Memória

Como mencionado anteriormente, suponha que você descubra que o OutputRoot submetido pelo sequenciador OP está incorreto e queira iniciar um 'desafio'. O processo de desafio requer a conclusão de uma série de interações on-chain, após o qual os contratos inteligentes relevantes determinarão se o sequenciador OP enviou um OutputRoot incorreto.

Para verificar a correção do OutputRoot on-chain usando contratos inteligentes, o método mais simples seria implementar um cliente de nó OP na cadeia Ethereum, usando os mesmos parâmetros de entrada do sequenciador OP, executando o mesmo programa e verificando se o resultado calculado corresponde. Esta abordagem é chamada de Programa à Prova de Falhas. Embora seja relativamente fácil de implementar off-chain, é muito difícil de executar na cadeia Ethereum devido a dois problemas:

1. Contratos inteligentes na Ethereum não podem obter automaticamente os parâmetros de entrada necessários para a prova de fraude.

2. O limite de gás do bloco do Ethereum é limitado e não suporta tarefas computacionais altamente complexas. Assim, não podemos implementar completamente o cliente OP node on-chain.

A primeira questão é equivalente a exigir que o contrato inteligente on-chain leia dados off-chain, o que pode ser resolvido usando uma solução semelhante a um oráculo. OP implantou o contrato PreimageOracle na cadeia Ethereum, e contratos relacionados à prova de fraude podem ler os dados necessários deste contrato. Teoricamente, qualquer pessoa pode enviar dados para este contrato, mas o sistema de prova de fraude da OP tem uma maneira de verificar se os dados são necessários, embora esse processo não seja detalhado aqui, pois não é crucial para o tópico principal deste artigo.

Para a segunda edição, a equipe de desenvolvimento da OP escreveu uma máquina virtual MIPS em Solidity para implementar algumas das funções do cliente de nó OP que são suficientes para o sistema à prova de fraude. MIPS é uma arquitetura comum de conjunto de instruções de CPU, e o código do sequenciador OP é escrito em linguagens de nível mais alto como Golang/Rust. Podemos compilar os programas Golang/Rust em programas MIPS e processá-los por meio da máquina virtual MIPS na cadeia Ethereum.

A equipe de desenvolvimento do OP escreveu um programa simplificado em Golang para a prova de fraude, que essencialmente imita os módulos no nó OP que executam transações, geram blocos e produzem o OutputRoot. No entanto, este programa simplificado ainda não pode ser 'executado completamente'. Em outras palavras, cada bloco OP contém muitas transações. Após processar este lote de transações, um OutputRoot é gerado. Embora você saiba que o OutputRoot de uma determinada altura do bloco está incorreto, seria irrealista executar todas as transações nesse bloco na cadeia para provar que o OutputRoot correspondente está errado. Além disso, durante a execução de cada transação, uma série de códigos de operação MIPS são processados em sequência. Seria impraticável executar toda essa série de códigos de operação na máquina virtual MIPS implementada em um contrato na cadeia, pois a sobrecarga computacional e o consumo de gás seriam muito grandes.

(Princípio de Funcionamento do Conjunto de Instruções MIPS)

Para resolver isso, a equipe da Optimism projetou um sistema interativo à prova de fraude destinado a analisar profundamente o fluxo de processamento de transações do OP. Observando todo o processo de cálculo do OutputRoot, o sistema identifica em qual opcode MIPS o sequenciador OP fez um erro na máquina virtual MIPS. Se um erro for confirmado, pode-se concluir que o OutputRoot fornecido pelo sequenciador é inválido.

Assim, a questão torna-se clara: o processo de empacotamento do sequenciador OP de transações em blocos pode ser decomposto no processamento ordenado de um grande número de códigos de operação MIPS. Após a execução de cada código de operação MIPS, o hash do estado da máquina virtual muda. Esses registros podem ser agregados em uma árvore de Merkle.

No processo interativo à prova de fraudes, o objetivo é determinar após qual opcode MIPS o hash de estado da máquina virtual do sequenciador OP se tornou incorreto, e então reproduzir o estado da máquina virtual MIPS on-chain, executando o opcode e observando se o hash de estado resultante corresponde ao enviado pelo sequenciador. Como apenas um opcode MIPS é executado on-chain, a complexidade é baixa e o processo de cálculo pode ser concluído na cadeia Ethereum. No entanto, para alcançar isso, precisamos fazer upload das informações de estado da máquina virtual MIPS, como dados de memória parcial, para a cadeia.

Em termos de implementação de código, os contratos inteligentes na cadeia Ethereum relacionados à à prova de fraude completarão o processo final de execução de opcode MIPS através de uma função chamada Step:

Os parâmetros na função acima, _stateData e _proof, representam os itens de dados dependentes para a execução de um único opcode MIPS, como o estado de registro da máquina virtual MIPS, o hash do estado de memória, etc. O diagrama é mostrado abaixo:

Podemos inserir esses parâmetros do ambiente da máquina virtual MIPS por meio de _stateData e _proof, executar uma única instrução MIPS on-chain e obter um resultado autoritativo. Se o resultado autoritativo obtido on-chain for diferente do resultado enviado pelo sequenciador, isso indica que o sequenciador é malicioso.

Geralmente nos referimos ao hash do _stateData como statehash, que pode ser entendido de forma aproximada como o hash de todo o estado da máquina virtual MIPS. Entre os vários campos em _stateData, memRoot é o design mais engenhoso. Como sabemos, durante a execução de um programa, uma grande quantidade de memória é usada, e a CPU interage com dados em determinados endereços de memória lendo e escrevendo. Portanto, quando executamos um código de operação MIPS on-chain através da função VM.Step, precisamos fornecer dados de certos endereços de memória na máquina virtual MIPS.

O OP usa uma arquitetura de 32 bits para a máquina virtual MIPS, e sua memória contém 2^27 endereços, que podem ser organizados em uma Árvore de Merkle binária de 28 níveis. Os nós folha no nível mais baixo são numerados 2^27, sendo que cada folha registra os dados de um endereço de memória específico da máquina virtual. O hash calculado a partir de todos os dados nas folhas é memRoot. O diagrama abaixo mostra a estrutura da árvore de Merkle que registra os dados da memória da máquina virtual MIPS:

Precisamos fornecer o conteúdo de determinados endereços de memória, e esse conteúdo é carregado para a cadeia Ethereum através do campo _proof na função de passo. Além disso, uma prova de Merkle baseada na árvore de Merkle de memória deve ser carregada para provar que os dados que você (ou o sequenciador) forneceu realmente existem na árvore de Merkle de memória, em vez de serem fabricados.

À prova interativa de fraude

Na seção anterior, abordamos a segunda questão completando a execução on-chain dos opcodes MIPS e a verificação do estado da máquina virtual. Mas como o desafiante e o sequenciador podem identificar a instrução de opcode MIPS específica em disputa?

Muitas pessoas podem ter lido explicações simples de provas de fraude interativas online e ouvido falar da abordagem de busca binária por trás delas. A equipe do OP desenvolveu um protocolo chamado Jogo de Disputa de Falhas (FDG). O protocolo FDG inclui dois papéis: o desafiante e o defensor.

Se descobrirmos que a OutputRoot submetida pelo sequenciador na cadeia está incorreta, podemos agir como o desafiante no FDG, com o sequenciador atuando como o defensor. Para ajudar a localizar o opcode MIPS que precisa ser processado na cadeia, o protocolo FDG exige que os participantes construam localmente uma árvore de Merkle chamada GameTree, cuja estrutura específica é a seguinte:

Podemos ver que o GameTree é bastante complexo, com uma estrutura aninhada hierárquica, consistindo de uma árvore de primeiro nível e subárvores de segundo nível. Em outras palavras, os nós folha da árvore de primeiro nível contêm uma subárvore.

Como mencionado anteriormente, cada bloco gerado pelo sequenciador contém uma OutputRoot, e os nós folha da árvore de primeiro nível na GameTree representam as OutputRoots de diferentes blocos. O desafiante e o defensor precisam interagir dentro da árvore de Merkle formada pelas OutputRoots para determinar qual OutputRoot do bloco está em disputa.

Uma vez identificado o bloco em disputa, mergulhamos no segundo nível da GameTree. A árvore de segundo nível também é uma árvore de Merkle, com seus nós folha sendo os hashes de estado da máquina virtual MIPS, como introduzido anteriormente. No cenário à prova de fraude, o desafiante e o defensor terão inconsistências nos nós folha da GameTree que constroem localmente. O hash de estado após processar um determinado opcode será diferente.

Após múltiplas interações em cadeia, as partes acabam por identificar exatamente o código de operação contestado, determinando o código de operação MIPS específico que precisa ser executado em cadeia.

Neste ponto, concluímos todo o processo de prova interativa de fraude. Para resumir, os dois mecanismos principais de prova interativa de fraude são:

1. O FDG (Fault Dispute Game) primeiro localiza o opcode MIPS que precisa ser executado on-chain, juntamente com as informações de estado da VM naquele momento;

2. A máquina virtual MIPS implementada na cadeia Ethereum executa o opcode, produzindo o resultado final.

ZK à prova de fraude

ZK à prova de fraude Como podemos ver, a abordagem tradicional à prova de fraude envolve interações muito complexas, exigindo múltiplas rodadas de interação no processo FDG e reexecutando instruções individuais on-chain. No entanto, essa solução tem vários desafios:

Várias rodadas de interação precisam ser acionadas na cadeia Ethereum, resultando em dezenas de interações que incorrem em custos significativos de gás. 2. O processo interativo à prova de fraude leva muito tempo e, uma vez que a interação começa, o Rollup não pode processar transações normalmente. 3. Implementar uma VM específica on-chain para reexecutar instruções é bastante complexo, com alta dificuldade de desenvolvimento.

Para lidar com esses problemas, a Optimism introduziu o conceito de À Prova de Fraude ZK. A ideia principal é que quando um desafiante levanta uma contestação, ele especifica a transação que ele acredita que precisa ser reenviada na cadeia. O sequenciador Rollup fornece uma prova ZK para a transação contestada, que é então verificada por um contrato inteligente na cadeia Ethereum. Se a verificação for bem-sucedida, conclui-se que não houve erros no processamento da transação e que o nó Rollup não está em falta.

No diagrama, o Desafianterefere-se à parte que levanta o desafio e oDefensor é o sequenciador OP. Em circunstâncias normais, o sequenciador OP gera blocos com base nas transações recebidas e envia os compromissos de estado de diferentes blocos para o Ethereum. Esses compromissos de estado podem ser vistos simplesmente como os valores de hash dos blocos. O Desafiante pode desafiar com base no hash do bloco. Depois de aceitar o desafio, o Defender gera uma prova ZK para demonstrar que os resultados da geração de blocos estão corretos. No diagrama, Bonsaié na verdade uma ferramenta de geração de prova ZK. Comparado aos comprovantes de fraude interativos, a maior vantagem da Prova de Fraude ZK é que ela substitui múltiplas rodadas de interação por uma única rodada de geração de prova ZK e verificação on-chain. Isso economiza significativamente tempo e reduz os custos de gás. Além disso, ao contrário dos ZK Rollups, os Rollups OP baseados na Prova de Fraude ZK não exigem a geração de provas toda vez que um bloco é produzido. Em vez disso, eles geram uma prova ZK temporariamente quando desafiados, o que também reduz os custos computacionais para os nós Rollup.

O conceito de ZK Fraud Proof também é adotado pelo BitVM2. Projetos que utilizam o BitVM2, como Bitlayer, Goat Network, ZKM e Fiama, implementam o programa de verificação de prova ZK por meio de scripts de Bitcoin, simplificando significativamente o tamanho dos programas que precisam ser levados à cadeia. Devido a limitações de espaço, este artigo não entrará em detalhes sobre este tópico. Fique atento para o nosso próximo artigo sobre BitVM2 para obter uma compreensão mais profunda do seu caminho de implementação!

Isenção de responsabilidade:

1. Este artigo é reproduzido de [GodRealmX], os direitos autorais pertencem ao autor original [Shew & Noah], se tiver alguma objeção à reimpressão, entre em contato com o Gate Learnequipe, e a equipe lidará com isso o mais rápido possível de acordo com os procedimentos relevantes.

2. Aviso Legal: As opiniões expressas neste artigo representam apenas as opiniões pessoais do autor e não constituem nenhum conselho de investimento.

3. Outras versões do artigo em outros idiomas são traduzidas pela equipe do Gate Learn e não são mencionadas em Gate.io, o artigo traduzido não pode ser reproduzido, distribuído ou plagiado.