Como é bem sabido, 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, se concentra em provas de fraude e fornece um novo modelo de segurança para a Camada 2 do Bitcoin ou pontes.

A BitVM lançou várias versões teóricas, desde a mais antiga BitVM0, que utilizava circuitos de portas lógicas como primitivas, até versões posteriores como 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 utilizam todos o BitVM como uma de suas tecnologias principais, implementando diferentes versões com base nesta 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 do BitVM. Considerando a conexão profundamente enraizada entre o BitVM e as provas de fraude, este artigo focará nas 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 Optimistic Rollup, e sua infraestrutura consiste em 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. Desde que seja capaz de executar um cliente de nó de Optimism, pode transferir os dados enviados pelo sequenciador para a sua máquina local. 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 carregar um hash de conjunto de estados incorreto para o Ethereum, o hash de conjunto de estados que você calcular localmente será diferente. Neste caso, você pode levantar um desafio através do sistema de prova de fraude. Com base no julgamento, o sistema irá impor restrições ou penalidades ao sequenciador ou não tomar nenhuma ação.

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

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

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

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

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

Como mencionado anteriormente, suponha que 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 que o sequenciador OP, executando o mesmo programa e verificando se o resultado calculado corresponde. Esta abordagem é chamada de Programa de 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. Os contratos inteligentes no Ethereum não podem obter automaticamente os parâmetros de entrada necessários para provas 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 totalmente o cliente de nó OP 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 à de um oráculo. OP implantou o contrato PreimageOracle na cadeia Ethereum, e os contratos relacionados à prova de fraude podem ler os dados necessários deste contrato. Teoricamente, qualquer pessoa pode carregar 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 este processo não seja elaborado aqui, pois não é crucial para o tópico principal deste artigo.

Para a segunda questão, a equipa de desenvolvimento do OP escreveu uma máquina virtual MIPS em Solidity para implementar algumas das funções do cliente do nó OP que são suficientes para o sistema de 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 através da máquina virtual MIPS na cadeia Ethereum.

A equipa de desenvolvimento do OP escreveu um programa simplificado em Golang para a prova de fraude, que basicamente 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, é gerado um OutputRoot. Embora saiba qual OutputRoot do bloco está incorreto, seria irrealista executar todas as transações desse bloco on-chain 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 num contrato on-chain, pois a sobrecarga computacional e o consumo de gás seriam demasiado elevados.

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

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

Assim, a questão torna-se clara: o processo do sequenciador OP de embalagem de transações em blocos pode ser decomposto no processamento ordenado de um grande número de opcodes MIPS. Após a execução de cada opcode MIPS, o hash de estado da máquina virtual muda. Estes registos podem ser agregados numa árvore de Merkle.

No processo interativo à prova de fraude, o objetivo é determinar após qual opcode MIPS o hash do estado da máquina virtual do sequenciador OP ficou incorreto, e depois reproduzir o estado da máquina virtual MIPS on-chain, executando o opcode e observando se o hash do estado resultante corresponde ao apresentado pelo sequenciador. Uma vez que 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 carregar as informações de estado da máquina virtual MIPS, como dados de memória parciais, 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 do 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 código de operação MIPS, como o estado do registro da máquina virtual MIPS, hash do estado da memória, etc. O diagrama é mostrado abaixo:

Podemos introduzir esses parâmetros de ambiente da máquina virtual MIPS através de _stateData e _proof, executar uma única instrução MIPS on-chain e obter um resultado autoritativo. Se o resultado autoritativo obtido on-chain difere do resultado submetido pelo sequenciador, 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 certos endereços de memória lendo e escrevendo. Portanto, quando executamos um opcode 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.

OP utiliza 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 número 2^27, sendo que cada folha grava 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 grava os dados da memória da máquina virtual MIPS:

Precisamos de fornecer o conteúdo de certos endereços de memória, e este 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 de Fraude Interativa

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

Muitas pessoas podem ter lido explicações simples de provas interativas de fraude online e ouvido falar da abordagem de pesquisa binária por trás delas. A equipa 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 o OutputRoot submetido pelo sequenciador on-chain está incorreto, podemos atuar como o desafiante no FDG, com o sequenciador atuando como defensor. Para ajudar a localizar o opcode MIPS que precisa ser processado on-chain, o protocolo FDG requer 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 hierárquica aninhada, composta por 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 um OutputRoot, e os nós folha da árvore de primeiro nível na GameTree representam os OutputRoots de diferentes blocos. O desafiante e o defensor precisam interagir dentro da árvore de Merkle formada pelos 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 os seus nós folha a serem os hashes de estado da máquina virtual MIPS, conforme introduzido anteriormente. No cenário de 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 opcode específico será diferente.

Após múltiplas interações on-chain, as partes acabam por identificar o exato opcode em disputa, determinando o opcode MIPS específico que precisa ser executado on-chain.

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

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

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

Prova de Fraude ZK

Prova de Fraude ZK Como podemos ver, a abordagem tradicional de prova de fraude envolve interações muito complexas, exigindo múltiplas rodadas de interação no processo FDG e repetindo instruções individuais na cadeia. No entanto, esta solução tem vários desafios:

Múltiplas rondas 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 de 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 resolver esses problemas, a Optimism introduziu o conceito de Prova de Fraude ZK. A ideia central é que quando um desafiante levanta um desafio, eles especificam a transação que acreditam que precisa ser repetida na cadeia. O sequenciador Rollup fornece uma prova ZK para a transação desafiada, 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 o Defensoré o sequenciador OP. Em circunstâncias normais, o sequenciador OP gera blocos com base em transações recebidas e submete os compromissos de estado de diferentes blocos ao Ethereum. Estes compromissos de estado podem ser simplesmente vistos como os valores de hash dos blocos. O Desafiante pode desafiar com base no hash do bloco. Após aceitar o desafio, o Defensor gera uma prova de 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. Em comparação com as provas de fraude interativas, a maior vantagem do ZK Fraud Proof é que ele substitui várias rodadas de interação por uma única rodada de geração de provas ZK e verificação on-chain. Isto poupa tempo e reduz significativamente os custos de gás. Além disso, ao contrário dos ZK Rollups, os OP Rollups baseados no ZK Fraud Proof não exigem a geração de provas sempre que um bloco é produzido. Em vez disso, eles só geram uma prova ZK temporariamente quando desafiados, o que também reduz os custos computacionais para nós de rollup.

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

Aviso Legal:

1. Este artigo é reproduzido a partir de [GateGodRealmX], os direitos de autor pertencem ao autor original [Shew & Noahse tiver alguma objeção à reimpressão, por favor contacte oGate Learnequipa, e a equipa irá 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 qualquer 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.