TL;DR

Introdução:

Este artigo fornece uma interpretação do whitepaper do BitVM, explicando a abordagem do BitVM: Os dados não precisam de estar inicialmente na cadeia; 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 na Blockchain BTC (Executando EVM ou Outros Opcodes VM)

Prefácio: Atualmente, o Bitcoin Layer 2 se tornou uma tendência, com dezenas de projetos se auto-identificando 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 proeminente do ecossistema Bitcoin.

No entanto, a maior parte da literatura existente sobre a BitVM não explica os seus princípios em termos leigos. Este artigo, baseado na nossa leitura do whitepaper de 8 páginas do BitVM e depois de consultar recursos relacionados com Taproot, árvores MAST e Bitcoin Script, oferece um resumo simplificado. Para facilitar a compreensão, alterámos algumas expressões das encontradas no whitepaper do BitVM, assumindo que o leitor tem algum conhecimento da Camada 2 e consegue compreender a ideia básica de "provas de fraude".

O conceito preliminar do BitVM pode ser resumido em algumas frases: elimina a necessidade de dados na cadeia, publicando e armazenando inicialmente dados fora da cadeia, com apenas um compromisso armazenado na cadeia de blocos. Em caso de contestação ou de prova de fraude, apenas os dados necessários são introduzidos na cadeia para demonstrar a sua associação com o compromisso na cadeia de blocos. Posteriormente, a rede principal de BTC verifica os dados na cadeia para detetar quaisquer problemas e se o produtor de dados (o nó que processa as transacções) se envolveu em actividades maliciosas. Esta abordagem adere ao princípio da Navalha de Occam - "As entidades não devem ser multiplicadas desnecessariamente" (se pode estar fora da cadeia, mantenha-a fora da cadeia).

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

1.Em primeiro lugar, um computador/processador é um sistema de entrada-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 de circuitos de portas lógicas. Desde que os circuitos de portas lógicas possam ser simulados, em teoria, é possível obter uma máquina de Turing que complete todas as tarefas computáveis. Isto significa que, se tiver recursos e mão de obra suficientes, pode reunir uma equipa de engenheiros para começar por simular os circuitos de portas lógicas utilizando o código rudimentar Bitcoin Script e, em seguida, utilizar uma enorme quantidade de circuitos de portas lógicas para implementar as funcionalidades do EVM ou WASM.

(Esta captura de ecrã é de um jogo educativo: "Turing Complete", onde o conteúdo principal é construir um processador de CPU completo, especialmente utilizando 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 então, é como construir o Empire State Building em Nova Iorque com blocos LEGO.

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

1. Então, porquê usar o Bitcoin Script para simular EVM ou WASM? Não é muito incómodo? A razão é que a maioria das soluções Bitcoin Layer 2 optam frequentemente por suportar linguagens de alto nível como Solidity ou Move, enquanto a única linguagem que pode atualmente ser executada diretamente na cadeia de blocos Bitcoin é o Bitcoin Script. Esta linguagem é primitiva, composta por um conjunto de códigos de operação únicos, e não é Turing completa.

(Um exemplo de código Bitcoin Script)

Se a camada 2 do Bitcoin tem como objetivo verificar provas de fraude na camada 1, tal como as soluções da camada 2 do Ethereum, como o Arbitrum, para herdar em grande medida a segurança do BTC, precisa de verificar diretamente "uma transação contestada" ou "um opcode contestado" na cadeia de blocos do BTC. Isso significa que os códigos de operação da linguagem Solidity / EVM usados pela camada 2 precisam ser reexecutados na blockchain do Bitcoin. O desafio resume-se a:

Utilize 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.

Por conseguinte, 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 portas lógicas que servem de representação intermédia (IR) entre "opcodes EVM -> Bitcoin Script opcodes".

(O whitepaper BitVM discute a abordagem geral para executar certas "instruções contestadas" na blockchain da Bitcoin)

De qualquer forma, o efeito final simulado é processar instruções, que originalmente só podiam ser tratadas em EVM / WASM, diretamente na blockchain Bitcoin. Embora esta solução seja viável, a dificuldade reside na forma de utilizar um grande número de circuitos de portas lógicas como forma intermédia para exprimir todos os códigos de funcionamento EVM/WASM. Além disso, a utilização de combinações de circuitos de portas lógicas para representar diretamente alguns fluxos de processamento de transacções extremamente complexos pode resultar numa enorme carga de trabalho.

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

As provas de fraude interactivas envolvem um termo conhecido como assert. Normalmente, o proponente da camada 2 (muitas vezes actuado por um sequenciador) publica uma afirmação na camada 1, declarando que determinados dados da transação e resultados da transição de estado são válidos e não contêm erros.

Se alguém considerar que o enunciado apresentado pelo proponente é problemático (os dados associados estão incorrectos), ocorre uma disputa. Nesta altura, o proponente e o desafiador trocam informações em rondas e utilizam um método de pesquisa binária nos dados em disputa para localizar rapidamente uma instrução de operação muito precisa e o seu segmento de dados associado.

Para esta instrução de operação contestada (Código OP), é necessário executá-la diretamente na Camada 1 juntamente com os 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 calcularam com o resultado de saída previamente publicado pelo proponente). Em Arbitrum, isto é conhecido como "Provas de Fraude de Passo Único". (No protocolo interativo de prova de fraude da Arbitrum, a pesquisa binária é utilizada para localizar rapidamente a instrução em causa e o seu resultado de execução e, em seguida, é enviada uma prova de fraude de um único passo para a camada 1 para verificação final).

Dê seguimento a este assunto:

1. O processo é interativo, com as duas partes a revezarem-se. Uma parte segmenta os dados históricos contidos num bloco de rollup e a outra parte aponta o segmento de dados que é problemático. Isto é 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 a transação e o resultado problemáticos e, em seguida, restringir a uma instrução de máquina específica dentro dessa transação que é contestada.

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

4. Uma vez que o desafiador e o desafiado tenham localizado a instrução de máquina a ser desafiada, o desafiador invoca oneStepProveExecution(), enviando uma prova de fraude de um único passo para demonstrar que existe um problema com o resultado da execução desta instrução de máquina.

(No protocolo interativo de prova de fraude do Arbitrum, o processo envolve a utilização de pesquisa binária para localizar rapidamente a instrução contestada e o seu resultado de execução a partir dos dados publicados pelo Proponente. Depois de identificar o dado ou o código de operação em causa, é enviada uma prova de fraude numa única fase para o nível 1 para verificação final).

Referências:

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

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

Neste ponto, o conceito de provas de fraude de etapa única torna-se bastante simples: a grande maioria das instruções de transação que ocorrem na Camada 2 não precisam de ser verificadas novamente na cadeia de blocos BTC. No entanto, se um determinado segmento de dados/opcode for contestado, deve ser repetido no nível 1.

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

O Arbitrum implementa os efeitos acima mencionados através de contratos no Ethereum, enquanto o BitVM pretende alcançar uma funcionalidade semelhante utilizando o Bitcoin Script para implementar bloqueios de tempo, multisig e outras características.

4. Depois de discutir as "Provas de fraude interactivas" e as "Provas de fraude numa única etapa", falaremos sobre as árvores MAST e as provas de Merkle. Anteriormente, mencionámos que, na solução BitVM, a grande quantidade de dados de transação e os circuitos de portas lógicas processados fora da cadeia na camada 2 não são diretamente colocados na cadeia. Apenas uma quantidade mínima de circuitos de dados/portões lógicos é colocada em cadeia quando necessário. No entanto, precisamos de uma forma de provar que estes dados, que estavam originalmente fora da cadeia e agora precisam de ser colocados na cadeia, não são fabricados. É aqui que entra em jogo o conceito de Compromisso em criptografia, e a Prova de Merkle é uma forma desse Compromisso.

Em primeiro lugar, vamos falar-lhe das árvores MAST. O nome completo de MAST é Merkelized Abstract Syntax Trees, que é uma transformação de AST (Abstract Syntax Trees) do domínio dos princípios de compilação em Merkle Trees. Então, o que é um AST? Em termos simples, é uma estrutura de dados em forma de árvore que decompõe um comando complexo num conjunto de unidades de operação básicas através da 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 de Merkle é a sua capacidade de "comprimir" dados de forma eficiente. Por exemplo, se quiser publicar um segmento de dados da árvore de Merkle na blockchain BTC quando necessário, ao mesmo tempo que torna credível que este segmento de dados existe verdadeiramente na árvore de Merkle e não é escolhido arbitrariamente, o que é que faz?

Basta-lhe registar previamente a raiz da árvore Merkle na cadeia de blocos. No futuro, bastará apresentar uma Prova de Merkle que prove que um dado existe 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 na blockchain BTC; é suficiente revelar a sua raiz antecipadamente como um compromisso. Quando necessário, a apresentação do segmento de dados + Merkle Proof/Branch é adequada. Isto reduz significativamente a quantidade de dados na cadeia, garantindo que os dados na cadeia existem efetivamente na árvore MAST. Além disso, a divulgação de apenas uma pequena parte dos segmentos de dados + Merkle Proof na cadeia de blocos 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: Porque é que o Plasma não suporta contratos inteligentes

(exemplo de árvore MAST)

Na solução BitVM, todos os circuitos de portas lógicas são expressos através de scripts Bitcoin, organizados numa enorme árvore MAST. As folhas inferiores desta árvore, indicadas como Content no diagrama, correspondem aos circuitos de portas lógicas implementados no script Bitcoin. O proponente da camada 2 publica frequentemente a raiz da árvore MAST na cadeia de blocos BTC, estando cada árvore MAST associada a uma transação que envolve todos os seus parâmetros de entrada/códigos de operação/circuitos de portas lógicas. Isto é um pouco semelhante ao Propositor do Arbitrum que publica Blocos Rollup na cadeia de blocos Ethereum.

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

(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 pormenores possam ainda ser um pouco obscuros, acredita-se que os leitores possam compreender a essência e os pontos principais do BitVM. No que diz respeito ao "compromisso de valor de bit" mencionado no seu documento técnico, este foi concebido para evitar que um proponente atribua tanto 0 como 1 aos valores de entrada de uma porta lógica quando desafiado e forçado a verificar o circuito da porta lógica em cadeia, criando assim ambiguidade e confusão.

Em resumo, o esquema BitVM começa por usar o script Bitcoin para expressar circuitos de portas lógicas, depois usa estes circuitos para expressar os opcodes da EVM/outras VMs, que por sua vez expressam o fluxo de processamento de qualquer instrução de transação dada, e finalmente organiza-os numa árvore Merkle/MAST. Se o fluxo de processamento de transacções representado por essa árvore for muito complexo, pode facilmente ultrapassar 100 milhões de folhas, pelo que é crucial minimizar o espaço de blocos ocupado pelos compromissos e o âmbito afetado pelas provas de fraude.

Embora uma prova de fraude numa única etapa exija apenas uma quantidade muito pequena de dados e um script de porta lógica na cadeia, a Árvore de Merkle completa deve ser armazenada fora da cadeia durante muito tempo, para que possa ser acedida na cadeia a qualquer momento se alguém a contestar. Cada transação numa camada 2 gera uma grande árvore de Merkle, e pode imaginar a pressão computacional e de armazenamento sobre os nós. A maioria das pessoas pode não querer gerir 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 optimistas baseados em provas de fraude não precisam de demasiados nós porque o 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 num momento crítico, a rede da camada 2 é segura.

No entanto, existem muitos desafios na conceção de soluções de camada 2 baseadas na BitVM, tais como:

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 comprimido numa prova zk, permitindo que os desafiantes contestem as etapas de verificação da prova zk. Isto pode reduzir significativamente a quantidade de dados na cadeia. No entanto, os pormenores específicos do desenvolvimento podem ser muito complexos.

2) Os proponentes e os proponentes devem gerar interacções fora da cadeia repetidamente. A forma como o protocolo deve ser concebido e como o processo de compromisso e desafio deve ser optimizado no fluxo de processamento exigirá um grande esforço intelectual.

Declaração de exoneração de responsabilidade：

1. Este artigo foi reimpresso a partir de[Geek Web3], Encaminhar o título original "Uma interpretação minimalista do BitVM: Como verificar a prova de fraude na cadeia BTC (executar o código de operação do EVM ou outra VM)", os direitos autorais pertencem ao autor original [Faust & Misty Moon]
   . Se houver objecções a esta reimpressão, contacte a equipa da Gate Learn, que tratará prontamente do assunto.
2. Declaração de exoneração de responsabilidade: Os pontos de vista e opiniões expressos neste artigo são da exclusiva responsabilidade do autor e não constituem um conselho de investimento.
3. As traduções do artigo para outras línguas são efectuadas pela equipa Gate Learn. A menos que seja mencionado, é proibido copiar, distribuir ou plagiar os artigos traduzidos.