TL;DR

Introdução:

Este artigo fornece uma interpretação do whitepaper do BitVM, explicando a abordagem do BitVM: Inicialmente, os dados não precisam estar na cadeia; eles são publicados e armazenados fora da cadeia, com apenas um compromisso armazenado na cadeia de blocos.

Título do artigo original encaminhado: Uma interpretação simplificada do BitVM: como verificar provas de fraude no blockchain do BTC (executando EVM ou outros opcodes de VM)

Prefácio: Atualmente, o Bitcoin Layer 2 se tornou uma tendência, com dezenas de projetos que se identificam como "Bitcoin Layer 2". Muitos deles, alegando serem "Rollups", afirmam que estão utilizando a abordagem proposta no whitepaper do BitVM, posicionando o BitVM como uma parte importante do ecossistema do Bitcoin.

No entanto, a maior parte da literatura existente sobre o BitVM não explica seus princípios em termos leigos. Este artigo, baseado em nossa leitura do whitepaper de 8 páginas do BitVM e após consultar recursos relacionados ao Taproot, às árvores MAST e ao Bitcoin Script, oferece um resumo simplificado. Para facilitar a compreensão, alteramos algumas expressões das encontradas no whitepaper do BitVM, presumindo que o leitor tenha algum conhecimento da Camada 2 e possa compreender a ideia básica de "provas de fraude".

O conceito preliminar do BitVM pode ser resumido em algumas frases: ele elimina a necessidade de dados na cadeia, inicialmente publicando e armazenando dados fora da cadeia, com apenas um compromisso armazenado na cadeia de blocos. Em casos de desafios ou prova de fraude, apenas os dados necessários são trazidos para a cadeia para demonstrar sua associação com o compromisso na cadeia de blocos. Posteriormente, a rede principal do BTC verifica os dados na cadeia em busca de problemas e se o produtor de dados (o nó que processa as transações) se envolveu em atividades mal-intencionadas. Essa abordagem segue o princípio da Navalha de Occam - "As entidades não devem ser multiplicadas desnecessariamente" (se puder ser fora da cadeia, mantenha-a fora da cadeia).

Texto principal: O chamado esquema de verificação de prova de fraude do blockchain BTC baseado no BitVM, em termos leigos:

1) Em primeiro lugar, um computador/processador é um sistema de entrada e saída composto por um grande número de circuitos de portas lógicas. Uma das ideias centrais do BitVM é usar o Bitcoin Script para simular os efeitos de entrada e saída dos circuitos de porta lógica. Desde que os circuitos de portas lógicas possam ser simulados, em teoria, uma máquina de Turing pode ser obtida, completando todas as tarefas computáveis. Isso significa que, se o senhor tiver recursos e mão de obra suficientes, poderá reunir uma equipe de engenheiros para primeiro simular os circuitos de porta lógica usando o código rudimentar do Bitcoin Script e, em seguida, usar uma quantidade enorme de circuitos de porta lógica para implementar as funcionalidades do EVM ou do WASM.

(Essa captura de tela é de um jogo educacional: "Turing Complete", em que o conteúdo principal é construir um processador de CPU completo, especialmente usando circuitos de portas lógicas como as portas NAND).

Alguns compararam a abordagem do BitVM à construção de um processador M1 no "Minecraft" usando circuitos de redstone. Ou, é como construir o Empire State Building em Nova York com blocos de LEGO.

(Diz-se que alguém passou um ano construindo um "processador" no "Minecraft").

1. Então, por que usar o Bitcoin Script para simular o EVM ou o WASM? Isso não é muito complicado? O motivo é que a maioria das soluções Bitcoin Layer 2 geralmente opta por oferecer suporte a linguagens de alto nível, como Solidity ou Move, enquanto a única linguagem que pode ser executada diretamente na blockchain do Bitcoin é o Bitcoin Script. Essa linguagem é primitiva, composta de vários códigos de operação exclusivos, e não é Turing completa.

(Um exemplo de código Bitcoin Script)

Se a Camada 2 do Bitcoin tiver como objetivo verificar provas de fraude na Camada 1, como as soluções da Camada 2 da Ethereum, como o Arbitrum, para herdar em grande parte a segurança do BTC, ela precisará verificar diretamente "uma transação contestada" ou "um opcode contestado" no blockchain do BTC. Isso significa que os opcodes da linguagem Solidity / EVM usados pela Camada 2 precisam ser reexecutados na blockchain do Bitcoin. O desafio se resume a:

Usar o Bitcoin Script, uma linguagem de programação nativa, mas rudimentar, do Bitcoin, para obter os efeitos da EVM ou de outras máquinas virtuais.

Portanto, do ponto de vista dos princípios de compilação, a abordagem BitVM traduz os opcodes EVM/WASM/JavaScript em opcodes Bitcoin Script, com circuitos de porta lógica servindo como uma representação intermediária (IR) entre "opcodes EVM -> opcodes Bitcoin Script".

(O whitepaper do BitVM discute a abordagem geral para executar determinadas "instruções contestadas" no blockchain do Bitcoin)

De qualquer forma, o efeito final simulado é processar instruções, que originalmente só poderiam ser tratadas no EVM / WASM, diretamente no blockchain do Bitcoin. Embora essa solução seja viável, a dificuldade está em como usar um grande número de circuitos de porta lógica como uma forma intermediária para expressar todos os códigos operacionais EVM/WASM. Além disso, o uso de combinações de circuitos de portas lógicas para representar diretamente alguns fluxos de processamento de transações extremamente complexos pode resultar em uma carga de trabalho enorme.

1. Vamos discutir outro conceito central mencionado no whitepaper do BitVM, que são as "Provas de fraude interativas", muito semelhantes às usadas pela Arbitrum.

As provas interativas de fraude envolvem um termo conhecido como assert. Normalmente, o proponente da Camada 2 (geralmente atuado por um sequenciador) publica uma afirmação na Camada 1, declarando que determinados dados de transação e resultados de transição de estado são válidos e livres de erros.

Se alguém acredita que a declaração enviada pelo proponente é problemática (os dados associados estão incorretos), ocorre uma disputa. Nesse ponto, o proponente e o desafiante trocam informações em rodadas e usam um método de pesquisa binária nos dados disputados para localizar rapidamente uma instrução de operação muito refinada e seu segmento de dados associado.

Para essa instrução de operação contestada (Código OP), é necessário executá-la diretamente na Camada 1 junto com seus parâmetros de entrada e validar o resultado de saída (os nós da Camada 1 comparam o resultado de saída que computaram com o resultado de saída publicado anteriormente pelo proponente). No Arbitrum, isso é conhecido como "Single-Step Fraud Proofs". (No protocolo interativo de prova de fraude da Arbitrum, a pesquisa binária é usada para localizar rapidamente a instrução contestada e seu resultado de execução e, em seguida, uma prova de fraude de etapa única é enviada para a Camada 1 para verificação final).

O senhor está acompanhando o assunto:

1. O processo é interativo, com as duas partes se revezando. Uma parte segmenta os dados históricos contidos em um bloco de rollup e a outra parte aponta qual segmento de dados é problemático. Isso é semelhante a um método binário (na realidade, um processo de redução progressiva do intervalo, N/K).

2. Posteriormente, é possível localizar ainda mais qual transação e resultado são problemáticos e, em seguida, restringir ainda mais a uma instrução de máquina específica dentro dessa transação que é contestada.

3. O contrato ChallengeManager verifica apenas se o "segmento de dados" produzido pela subdivisão dos dados originais é válido.

4. Uma vez que o desafiante e o desafiado tenham localizado a instrução de máquina a ser desafiada, o desafiante invoca oneStepProveExecution(), enviando uma prova de fraude de etapa única para demonstrar que há um problema com o resultado da execução dessa instrução de máquina.

(No protocolo interativo de prova de fraude do Arbitrum, o processo envolve o uso de pesquisa binária para localizar rapidamente a instrução contestada e seu resultado de execução a partir dos dados publicados pelo Proponente. Depois de identificar a parte controversa dos dados ou do código operacional, uma prova de fraude de etapa única é enviada à Camada 1 para verificação final).

Referências:

O ex-embaixador técnico da Arbitrum explica a estrutura de componentes da Arbitrum (Parte 1)

(Fluxograma interativo de prova de fraude da Arbitrum, a explicação é relativamente grosseira)

Nesse ponto, o conceito de provas de fraude em uma única etapa torna-se bastante simples: a grande maioria das instruções de transação que ocorrem na Camada 2 não precisa ser verificada novamente na blockchain do BTC. No entanto, se um determinado segmento de dados/opcode em disputa for contestado, ele deverá ser reproduzido na Camada 1.

Se o resultado da verificação indicar que os dados publicados anteriormente pelo Proponente são problemáticos, os ativos em jogo do Proponente serão reduzidos. Se a culpa for do Challenger, os ativos em jogo do Challenger serão reduzidos. Os provedores que não respondem aos desafios em tempo hábil também podem ser cortados.

O Arbitrum implementa os efeitos mencionados acima por meio de contratos no Ethereum, enquanto o BitVM visa obter uma funcionalidade semelhante usando o Bitcoin Script para implementar bloqueios de tempo, multisig e outros recursos.

4. depois de discutir "Provas de fraude interativas" e "Provas de fraude de etapa única", falaremos sobre árvores MAST e provas de Merkle. Anteriormente, mencionamos que, na solução BitVM, a grande quantidade de dados de transações e os circuitos de portas lógicas processados fora da cadeia na Camada 2 não são colocados diretamente na cadeia. Apenas uma quantidade mínima de circuitos de dados/portões lógicos é colocada na cadeia quando necessário. No entanto, precisamos de uma maneira de provar que esses dados, que originalmente estavam fora da cadeia e agora precisam ser colocados na cadeia, não são fabricados. É nesse ponto que o conceito de compromisso na criptografia entra em ação, e a prova de Merkle é uma forma desse compromisso.

Primeiro, vamos falar sobre as árvores MAST. O nome completo do MAST é Merkelized Abstract Syntax Trees (Árvores de sintaxe abstrata merkelizadas), que é uma transformação de AST (Abstract Syntax Trees) do domínio dos princípios do compilador em Merkle Trees. Então, o que é um AST? Em termos simples, é uma estrutura de dados em forma de árvore que divide um comando complexo em várias unidades operacionais básicas por meio de análise lexical.

(Um exemplo de uma árvore AST seria a decomposição de cálculos simples como "x=2, y=x*3" em códigos de operação e dados subjacentes. )

A árvore MAST, portanto, é o resultado da aplicação da Merkleization a uma árvore AST, suportando Merkle Proofs. Uma vantagem das árvores Merkle é sua capacidade de "comprimir" dados com eficiência. Por exemplo, se o senhor quiser publicar um segmento de dados da árvore de Merkle no blockchain do BTC quando necessário e, ao mesmo tempo, tornar crível que esse segmento de dados realmente existe na árvore de Merkle e não foi escolhido arbitrariamente, o que o senhor faz?

O senhor simplesmente registra a raiz da árvore Merkle no blockchain com antecedência. No futuro, será suficiente apresentar uma prova de Merkle que comprove a existência de um dado na árvore de Merkle correspondente à raiz.

(A relação entre Merkle Proof/Branch e Root)

Assim, não há necessidade de armazenar a árvore MAST completa no blockchain do BTC; basta divulgar sua raiz antecipadamente como um compromisso. Quando necessário, a apresentação do segmento de dados + Merkle Proof/Branch é adequada. Isso reduz bastante a quantidade de dados na cadeia e, ao mesmo tempo, garante que os dados na cadeia existam de fato na árvore do MAST. Além disso, a divulgação de apenas uma pequena parte dos segmentos de dados + Merkle Proof no blockchain do BTC, em vez de todos os dados, pode aumentar significativamente a proteção da privacidade.

Referências:Retenção de dados e prova de fraude: Por que o Plasma não é compatível com contratos inteligentes

(Exemplo de árvore MAST)

Na solução do BitVM, todos os circuitos de porta lógica são expressos usando scripts de Bitcoin, organizados em uma enorme árvore MAST. As folhas inferiores dessa árvore, indicadas como Content no diagrama, correspondem aos circuitos de porta lógica implementados no script Bitcoin. O proponente da camada 2 publica frequentemente a raiz da árvore MAST no blockchain do BTC, com cada árvore MAST associada a uma transação envolvendo todos os seus parâmetros de entrada/códigos de operação/circuitos de porta lógica. Isso é um pouco semelhante ao Proposer da Arbitrum que publica blocos de rollup na blockchain da Ethereum.

Quando surge uma disputa, um desafiante declara na blockchain do BTC qual é a raiz que deseja desafiar e, em seguida, pede ao Proponente que revele um segmento de dados específico correspondente à raiz. Em seguida, o Proponente apresenta uma Prova de Merkle, revelando continuamente pequenos segmentos dos dados da árvore MAST na cadeia até que o circuito de porta lógica em disputa seja localizado em conjunto com o desafiante. Depois disso, um Slash pode ser executado.

(Fonte: https://medium.com/crypto-garage/deep-dive-into-bitvm-computing-paradigm-to-express-turing-complete-bitcoin-contracts-1c6cb05edfca）

1. Até este ponto, os aspectos mais importantes da solução BitVM foram amplamente abordados. Embora alguns detalhes ainda possam ser um pouco obscuros, acredita-se que os leitores possam compreender a essência e os pontos principais do BitVM. Com relação ao "compromisso de valor de bit" mencionado em seu whitepaper, ele foi projetado para evitar que um Proponente atribua tanto 0 quanto 1 aos valores de entrada de uma porta lógica quando desafiado e forçado a verificar o circuito da porta lógica na cadeia, criando assim ambiguidade e confusão.

Em resumo, o esquema BitVM começa usando o script Bitcoin para expressar circuitos de porta lógica e, em seguida, usa esses circuitos para expressar os opcodes do EVM/outras VMs, que, por sua vez, expressam o fluxo de processamento de qualquer instrução de transação e, por fim, os organiza em uma árvore Merkle/MAST. Se o fluxo de processamento de transações representado por essa árvore for muito complexo, ele poderá facilmente ultrapassar 100 milhões de folhas, portanto, é fundamental minimizar o espaço de bloco ocupado pelos compromissos e o escopo afetado pelas provas de fraude.

Embora uma prova de fraude de etapa única exija apenas uma quantidade muito pequena de dados e um script de porta lógica na cadeia, a Merkle Tree completa deve ser armazenada fora da cadeia por um longo período, para que possa ser acessada na cadeia a qualquer momento se alguém a contestar. Cada transação em uma camada 2 gera uma grande Merkle Tree, e é possível imaginar a pressão computacional e de armazenamento sobre os nós. A maioria das pessoas talvez não queira executar nós (no entanto, esses dados históricos podem ser eliminados gradualmente, e a rede B^2 introduz especificamente provas de armazenamento zk semelhantes às do Filecoin para incentivar os nós de armazenamento a preservar os dados históricos a longo prazo).

No entanto, os Rollups otimistas baseados em provas de fraude não precisam de muitos nós porque seu modelo de confiança é 1/N, o que significa que, desde que um dos N nós seja honesto e possa iniciar uma prova de fraude em um momento crítico, a rede da Camada 2 estará segura.

No entanto, há muitos desafios no projeto de soluções de camada 2 com base no BitVM, como, por exemplo:

1) Teoricamente, para comprimir ainda mais os dados, não é necessário verificar os opcodes diretamente na Camada 1. O fluxo de processamento dos opcodes pode ser ainda mais compactado em uma prova zk, permitindo que os desafiantes contestem as etapas de verificação da prova zk. Isso poderia reduzir significativamente a quantidade de dados na cadeia. No entanto, os detalhes específicos do desenvolvimento podem ser muito complexos.

2) Os proponentes e desafiantes precisam gerar interações fora da cadeia repetidamente. O modo como o protocolo deve ser projetado e como o processo de compromisso e desafio deve ser otimizado no fluxo de processamento exigirá muito esforço intelectual.

Isenção de responsabilidade：

1. Este artigo foi reimpresso de[Geek Web3], Forward the Original Title "A minimalist interpretation of BitVM: How to verify fraud proof on the BTC chain (execute the operation code of EVM or other VM)", os direitos autorais pertencem ao autor original [Faust & Misty Moon].
   . Se houver objeções a esta reimpressão, entre em contato com a equipe do Gate Learn, que tratará do assunto imediatamente.
2. Isenção de responsabilidade: Os pontos de vista e opiniões expressos neste artigo são de responsabilidade exclusiva do autor e não constituem consultoria de investimento.
3. As traduções do artigo para outros idiomas são feitas pela equipe do Gate Learn. A menos que mencionado, é proibido copiar, distribuir ou plagiar os artigos traduzidos.