Resumo:

A Delphi Digital lançou recentemente um relatório intitulado "O Amanhecer da Programabilidade do Bitcoin: Abrindo Caminho para Rollups", que esboça conceitos-chave relacionados aos Rollups do Bitcoin, incluindo a suíte BitVM, restrições OP_CAT e Covenant, a camada DA do ecossistema Bitcoin, pontes e quatro grandes soluções de Camada 2 usando BitVM: Bitlayer, Citrea, Yona e Bob. Embora o relatório forneça uma visão geral da tecnologia da Camada 2 do Bitcoin, ele permanece bastante geral e carece de descrições detalhadas, tornando-o um pouco difícil de entender. O Geek Web3 expandiu o relatório da Delphi para ajudar mais pessoas a entender sistematicamente tecnologias como BitVM.

Vamos trabalhar com a equipe de pesquisa da Bitlayer e a comunidade chinesa do BitVM para lançar uma série chamada 'Aproximando-se do BTC'. Esta série irá focar em tópicos-chave como BitVM, OP_CAT e pontes cross-chain do Bitcoin, com o objetivo de desmistificar as tecnologias da Camada 2 do Bitcoin para um público mais amplo e pavimentar o caminho para mais entusiastas.

Algumas meses atrás, Robin Linus, o líder da ZeroSync, publicou um artigo intitulado "BitVM: Compute Anything on Bitcoin", introduzindo oficialmente o conceito de BitVM e impulsionando a tecnologia Bitcoin Layer 2. Isso é considerado uma das inovações mais revolucionárias no ecossistema Bitcoin, despertando interesse e atividade significativos no espaço Bitcoin Layer 2. Atraiu projetos notáveis como Bitlayer, Citrea e BOB, trazendo nova energia para o mercado. Desde então, mais pesquisadores se juntaram para melhorar o BitVM, resultando em várias versões iterativas como BitVM1, BitVM2, BitVMX e BitSNARK. A visão geral geral é a seguinte:

1. Robin Linus introduziu inicialmente o white paper de implementação do BitVM no ano passado, que é baseado em um circuito conceitual de portão lógico e é conhecido como BitVM0.
2. Em apresentações e entrevistas posteriores, Robin Linus introduziu informalmente o conceito de BitVM com base em uma CPU teórica, referida como BitVM1. Isso é semelhante ao sistema de prova de fraude Cannon da Optimism e pode simular o efeito de uma CPU de uso geral off-chain usando scripts do Bitcoin.
3. Robin Linus também propôs BitVM2, um protocolo de prova de fraude não interativo de um único passo sem permissão.
4. Membros da Rootstock Labs e Fairgate Labs lançaram um white paper sobre BitVMX. Similar ao BitVM1, eles têm como objetivo simular o efeito de uma CPU de uso geral off-chain usando scripts Bitcoin.

Atualmente, a construção do ecossistema de desenvolvedores relacionados ao BitVM está se tornando cada vez mais clara, e a melhoria iterativa das ferramentas periféricas também é visível a olho nu. Comparado com o ano passado, o ecossistema BitVM de hoje se tornou 'vagamente visível' a partir do inicial 'castelo no ar', o que também atraiu cada vez mais pessoas. Mais desenvolvedores e VCs estão correndo para o ecossistema Bitcoin.

Para a maioria das pessoas, entender BitVM e os termos técnicos relacionados à Camada 2 do Bitcoin não é fácil. Requer um entendimento sistemático do conhecimento fundamental, especialmente scripts do Bitcoin e Taproot. Os recursos online existentes costumam ser muito longos e cheios de detalhes irrelevantes ou muito breves para serem claros. Nosso objetivo é resolver esses problemas usando uma linguagem clara e concisa para ajudar mais pessoas a entender os conceitos fundamentais da Camada 2 do Bitcoin e construir uma compreensão abrangente do sistema BitVM.

MATT e Compromissos: O Conceito Principal do BitVM

O conceito central do BitVM gira em torno de MATT, que significa Merkleize All The Things. Esta abordagem utiliza uma Árvore de Merkle, uma estrutura de armazenamento de dados hierárquica, para representar a execução de programas complexos. O objetivo é permitir a verificação nativa da prova de fraude na rede Bitcoin. MATT pode capturar os detalhes de um programa complexo e suas atividades de processamento de dados, mas não publica esses extensos dados diretamente na blockchain do Bitcoin devido ao seu tamanho grande. Em vez disso, a abordagem MATT armazena esses dados em uma árvore de Merkle off-chain e publica apenas a Raiz de Merkle (o resumo mais alto da árvore de Merkle) na blockchain. A árvore de Merkle contém principalmente três componentes-chave:

• Código de script de contrato inteligente
• Dados necessários para o contrato
• Traços de execução do contrato (registros de alterações na memória e nos registradores da CPU durante a execução de contratos inteligentes em máquinas virtuais como EVM)

(Um diagrama esquemático simples da Árvore de Merkle. Sua Raiz de Merkle é calculada a partir dos 8 fragmentos de dados na parte inferior da imagem através de hash em várias camadas)

No esquema MATT, apenas a raiz de Merkle extremamente pequena é armazenada na cadeia, e o conjunto de dados completo contido na Árvore de Merkle é armazenado fora da cadeia. Isso usa uma ideia chamada "compromisso". Aqui está uma explicação do que é "Compromisso".

Uma promessa é como uma declaração sucinta, podemos entendê-la como a “impressão digital” obtida após a compressão de uma grande quantidade de dados. Em geral, a pessoa que emite um “compromisso” na cadeia afirmará que certos dados armazenados fora da cadeia são precisos. Esses dados fora da cadeia devem corresponder a uma declaração concisa, e esta declaração é o “compromisso.”

Em algum momento, o hash dos dados pode ser usado como um "compromisso" com os próprios dados. Outros esquemas de compromisso incluem o compromisso KZG ou a Árvore de Merkle. No protocolo usual de prova de fraude da Layer2, o editor de dados publicará o conjunto de dados completo fora da cadeia e um compromisso de publicar o conjunto de dados na cadeia. Se alguém descobrir dados inválidos no conjunto de dados fora da cadeia, o compromisso de dados na cadeia será contestado.

Por meio do Compromisso, a segunda camada pode comprimir uma grande quantidade de dados e publicar apenas seu “compromisso” na cadeia do Bitcoin. Claro, também é necessário garantir que o conjunto de dados completo liberado fora da cadeia possa ser observado pelo mundo exterior.

Atualmente, os principais esquemas BitVM, como BitVM0, BitVM1, BitVM2 e BitVMX, seguem todos uma estrutura abstrata semelhante:

1. Descomposição do programa e compromisso: Inicialmente, um programa complexo é decomposto em numerosos opcodes básicos (compilação). Os rastros de execução desses opcodes (basicamente as mudanças de estado quando um programa é executado na CPU e na memória, conhecido como Trace) são registrados. Todos os dados, incluindo o Trace e os opcodes, são organizados em um conjunto de dados, e um compromisso é gerado para este conjunto de dados. Vários esquemas de compromisso podem ser usados, como árvores de Merkle, PIOPs (vários algoritmos ZK) e funções de hash.
2. Staking de Ativos e Pré-assinatura: O editor de dados e o verificador devem bloquear uma certa quantidade de ativos na blockchain por meio de pré-assinatura, com condições restritivas específicas. Essas condições desencadeiam ações para eventos futuros potenciais. Se o editor de dados agir de forma maliciosa, o verificador pode apresentar provas e tomar os ativos do editor de dados.
3. Publicação de Dados e Compromissos: O editor de dados publica o compromisso on-chain e o conjunto de dados completo off-chain. O verificador recupera e verifica o conjunto de dados em busca de erros. Cada parte do conjunto de dados off-chain está vinculada ao compromisso on-chain.
4. Desafio e Penalidade: Se o verificador encontrar erros nos dados fornecidos pelo editor de dados, eles trazem esta parte dos dados on-chain para verificação direta (exigindo dados detalhados). Este processo segue a lógica das provas de fraude. Se os dados forem confirmados como inválidos, os ativos do editor de dados serão tomados pelo verificador desafiante. Em resumo, o editor de dados, Alice, revela todas as pistas geradas durante a execução de transações da Camada 2 off-chain e publica o compromisso correspondente on-chain. Para provar que uma parte dos dados está incorreta, você deve primeiro mostrar ao nó Bitcoin a que esses dados se referem no compromisso on-chain, confirmando que foram divulgados por Alice, e então o nó Bitcoin verifica a precisão dos dados. Tendo entendido a ideia geral do BitVM, todas as variantes do BitVM aderem a este paradigma básico. Em seguida, vamos nos aprofundar em algumas tecnologias-chave usadas neste processo, começando com os fundamentos dos scripts do Bitcoin, Taproot e pré-assinaturas.

O que é o Script do Bitcoin?

Compreender o Bitcoin pode ser mais desafiador do que o Ethereum, pois mesmo as transações mais simples envolvem vários conceitos-chave. Estes incluem UTXO (Unspent Transaction Output), scripts de bloqueio (também conhecidos como ScriptPubKey) e scripts de desbloqueio (também conhecidos como ScriptSig). Vamos primeiro analisar esses conceitos fundamentais.

(Um exemplo de código de script Bitcoin consiste em opcodes de nível inferior em comparação com linguagens de alto nível) O método de representação de ativos do Ethereum é semelhante a sistemas como Alipay ou WeChat, onde cada transação simplesmente ajusta os saldos de diferentes contas. Esta abordagem baseada em contas trata os saldos de ativos apenas como números associados às contas. Em contraste, a representação de ativos do Bitcoin é mais parecida com lidar com ouro, onde cada pedaço de ouro (UTXO) é marcado com um proprietário. Uma transação do Bitcoin essencialmente destrói o antigo UTXO e cria um novo, com a mudança de propriedade no processo. Um UTXO do Bitcoin inclui dois componentes principais:

• Quantidade: Medido em “satoshis” (um BTC equivale a cem milhões de satoshis);
• Script de Bloqueio (ScriptPubKey): Isso define as condições necessárias para desbloquear o UTXO. A propriedade do UTXO do Bitcoin é determinada pelo script de bloqueio. Por exemplo, se você quiser transferir seu UTXO para o Sam, você iniciaria uma transação que destrói seu UTXO e cria um novo com a condição 'apenas Sam pode desbloquear'. Quando Sam quiser usar esses bitcoins, ele deve enviar um script de desbloqueio (ScriptSig). Neste script, Sam fornece sua assinatura digital para provar sua identidade. Se o script de desbloqueio corresponder ao script de bloqueio original, Sam pode então desbloquear os bitcoins e transferi-los para outra pessoa.

(O script de desbloqueio deve corresponder ao script de bloqueio) Nas transações de Bitcoin, cada transação consiste em múltiplas entradas e saídas. Cada entrada especifica uma UTXO a ser desbloqueada e fornece um script de desbloqueio para fazê-lo, que então desbloqueia e destrói a UTXO. As saídas da transação mostram as UTXOs recém-criadas e exibem publicamente os scripts de bloqueio associados. Por exemplo, em uma entrada de transação, você prova que é o Sam desbloqueando várias UTXOs que outros lhe enviaram, destruindo-as no processo. Em seguida, você cria várias novas UTXOs e especifica que xxx pode desbloqueá-las no futuro.

Especificamente, nos dados de entrada de uma transação, você precisa declarar quais UTXOs pretende desbloquear e especificar a “localização de armazenamento” desses dados UTXO. É importante entender que o Bitcoin e o Ethereum lidam com isso de maneira diferente. O Ethereum usa contas de contrato e Contas de Propriedade Externa (EOAs) para armazenar dados, com saldos de ativos registrados como números sob essas contas. Todas essas informações são armazenadas em um banco de dados chamado “estado do mundo”. Quando ocorre uma transação, o “estado do mundo” atualiza diretamente os saldos de contas específicas, facilitando a localização dos dados. Em contraste, o Bitcoin não tem um “estado do mundo”. Em vez disso, os dados de ativos são distribuídos em blocos anteriores como UTXOs não gastos, armazenados individualmente na Saída de cada transação.

Se deseja desbloquear um determinado UTXO, deve indicar em qual saída de transação as informações do UTXO existem no passado e mostrar o ID da transação (que é seu hash). Deixe o nó do Bitcoin procurá-lo no histórico. Se deseja consultar o saldo de Bitcoin de um determinado endereço, precisa percorrer todos os blocos desde o início para encontrar o UTXO desbloqueado associado ao endereço xx.

Quando você costuma usar uma carteira Bitcoin, você pode verificar rapidamente o saldo de Bitcoin de um determinado endereço. Isso geralmente ocorre porque o próprio serviço de carteira indexa todos os endereços escaneando blocos, facilitando nossa consulta rápida.

(Quando você cria uma transação para transferir seu UTXO para outra pessoa, você precisa especificar a localização desse UTXO no histórico de transações do Bitcoin, referenciando o hash/ID da transação a que ele pertence.) Curiosamente, os resultados das transações do Bitcoin são calculados off-chain. Quando os usuários geram transações em seus dispositivos locais, eles devem criar todos os Inputs e Outputs antecipadamente, calculando efetivamente os outputs da transação. A transação é então transmitida para a rede do Bitcoin, verificada pelos nós e adicionada ao blockchain. Esse modelo de "cálculo off-chain - verificação on-chain" é completamente diferente do Ethereum. No Ethereum, você só precisa fornecer parâmetros de entrada da transação, e os resultados da transação são calculados e outputados pelos nós do Ethereum. Além disso, o script de bloqueio de um UTXO pode ser personalizado. Você pode definir um UTXO como "desbloqueável pelo proprietário de um endereço de Bitcoin específico", exigindo que o proprietário forneça uma assinatura digital e chave pública (P2PKH). Em transações Pay-to-Script-Hash (P2SH), você pode adicionar um Script Hash ao script de bloqueio do UTXO. Qualquer pessoa que possa apresentar o script correspondente a este hash e atender às condições especificadas no script pode desbloquear o UTXO. O script Taproot, no qual BitVM se baseia, usa recursos semelhantes aos do P2SH.

Como acionar o script Bitcoin

Para entender o mecanismo de acionamento dos scripts do Bitcoin, vamos começar com o exemplo P2PKH, que significa "Pagar para o Hash da Chave Pública". Nesta configuração, o script de bloqueio de um UTXO contém um hash de chave pública e, para desbloqueá-lo, a chave pública correspondente deve ser fornecida. Esse mecanismo está alinhado com o processo padrão das transações de Bitcoin. Neste contexto, um nó de Bitcoin deve verificar se a chave pública no script de desbloqueio corresponde ao hash de chave pública especificado no script de bloqueio. Essencialmente, verifica se a "chave" fornecida pelo usuário se encaixa no "bloqueio" definido pelo UTXO. Em mais detalhes, sob o esquema P2PKH, quando um nó de Bitcoin recebe uma transação, ele combina o script de desbloqueio do usuário (ScriptSig) com o script de bloqueio (ScriptPubKey) do UTXO a ser desbloqueado e então executa este script combinado no ambiente de execução de scripts do Bitcoin. A imagem abaixo ilustra o resultado concatenado antes da execução:

Os leitores podem não estar familiarizados com o ambiente de execução de script BTC, então vamos apresentá-lo brevemente. Os scripts Bitcoin consistem em dois elementos: dados e opcodes. Esses elementos são empurrados para uma pilha sequencialmente da esquerda para a direita e executados de acordo com a lógica especificada para produzir o resultado final (para uma explicação do que é uma pilha, os leitores podem consultar o ChatGPT). No exemplo acima, o lado esquerdo mostra o script de desbloqueio (ScriptSig) fornecido por alguém, que inclui sua assinatura digital e chave pública. O lado direito mostra o script de bloqueio (ScriptPubKey), que contém uma série de opcodes e dados definidos pelo criador do UTXO ao gerar esse UTXO (entender a ideia geral é suficiente; não precisamos nos aprofundar no significado de cada opcode). Os opcodes no script de bloqueio do lado direito, como DUP, HASH160 e EQUALVERIFY, fazem o hash da chave pública do script de desbloqueio do lado esquerdo e a comparam com o hash de chave pública predefinido no script de bloqueio. Se corresponderem, ele confirma que a chave pública no script de desbloqueio corresponde ao hash de chave pública no script de bloqueio, passando pela primeira verificação. No entanto, há um problema: o conteúdo do script de bloqueio é visível publicamente no blockchain, o que significa que qualquer pessoa pode ver o hash da chave pública. Portanto, qualquer pessoa poderia enviar a chave pública correspondente e alegar falsamente ser a pessoa autorizada. Para resolver isso, depois de verificar a chave pública e o hash de chave pública, o sistema também deve verificar se o iniciador da transação realmente controla a chave pública, o que envolve a verificação da assinatura digital. O opcode CHECKSIG no script de bloqueio manipula essa verificação. Em resumo, no esquema P2PKH, o script de desbloqueio do iniciador da transação deve incluir a chave pública e a assinatura digital. A chave pública deve corresponder ao hash de chave pública especificado no script de bloqueio e a assinatura digital deve estar correta. Essas condições devem ser atendidas para desbloquear com sucesso o UTXO.

(Esta é uma ilustração dinâmica: Um diagrama de scripts de desbloqueio do Bitcoin sob o esquema P2PKH
Fonte:https://learnmeabitcoin.com/technical/script)

É importante notar que a rede Bitcoin suporta vários tipos de transações além de Pagar para Chave Pública/Hash da Chave Pública, como P2SH (Pagar para Hash de Script). O tipo específico de transação depende de como o script de bloqueio é configurado quando o UTXO é criado.

É importante entender que, sob o esquema P2SH, o script de bloqueio pode pré-definir um Hash de Script e o script de desbloqueio deve fornecer o conteúdo completo do script que corresponde a este Hash de Script. O nó Bitcoin pode então executar este script e, se incluir lógica de verificação de assinatura múltipla, efetivamente habilita carteiras de assinatura múltipla na blockchain do Bitcoin. No esquema P2SH, o criador da UTXO precisa informar a pessoa que desbloqueará a UTXO no futuro sobre o conteúdo do script correspondente ao Hash de Script. Desde que ambas as partes estejam cientes do conteúdo do script, podemos implementar lógica de negócios ainda mais complexa do que apenas assinatura múltipla. Também vale ressaltar que a blockchain do Bitcoin não registra diretamente quais UTXOs estão vinculados a quais endereços. Em vez disso, registra quais UTXOs podem ser desbloqueados por qual hash de chave pública ou hash de script. No entanto, podemos derivar rapidamente o endereço correspondente (a sequência de caracteres que parece um absurdo exibido nas interfaces de carteira) do hash de chave pública ou hash de script.

A razão pela qual você pode ver a quantidade de Bitcoin associada a um endereço específico em exploradores de bloco e interfaces de carteira é que esses serviços analisam e interpretam os dados da blockchain para você. Eles escaneiam todos os blocos e, com base no hash da chave pública ou hash do script declarado nos scripts de bloqueio, calculam o “endereço” correspondente. Isso lhes permite exibir quanto Bitcoin está associado a esse endereço.

Testemunha Segregada e Testemunha

Entender o P2SH nos aproxima do Taproot, um componente crucial para BitVM. No entanto, antes de mergulhar no Taproot, é essencial compreender o conceito de Testemunha e Testemunha Segregada (SegWit). Revisar os scripts de desbloqueio e bloqueio, bem como o processo de desbloqueio UTXO, destaca um problema: a assinatura digital para uma transação está incluída no script de desbloqueio. Ao gerar esta assinatura, o script de desbloqueio em si não pode ser parte dos dados sendo assinados (pois os parâmetros usados para gerar a assinatura não podem incluir a assinatura em si mesma).

Consequentemente, a assinatura digital só pode cobrir partes dos dados da transação fora do script de desbloqueio, o que significa que não pode proteger totalmente todos os dados da transação. Isso leva a uma vulnerabilidade em que um intermediário pode modificar ligeiramente o script de desbloqueio sem afetar a verificação da assinatura. Por exemplo, nós de Bitcoin ou pools de mineração podem inserir dados adicionais no script de desbloqueio. Embora essa alteração não afete a verificação e o resultado da transação, ela muda ligeiramente os dados da transação, o que, por sua vez, altera o hash/ID da transação calculada. Esse problema é conhecido como maleabilidade da transação.

O problema com isso é que se você planeja iniciar múltiplas transações sequenciais que dependem umas das outras (por exemplo, a transação 3 referencia a saída da transação 2, e a transação 2 referencia a saída da transação 1), as transações subsequentes devem referenciar os hashes das transações anteriores. Qualquer intermediário, como uma pool de mineração ou nó Bitcoin, pode fazer pequenas modificações no script de desbloqueio, causando o hash da transação diferir da sua expectativa uma vez que está na blockchain.

Essa discrepância pode invalidar sua sequência pré-planejada de transações interdependentes. Esse problema é particularmente relevante no contexto das pontes de DLC e BitVM2, onde lotes de transações sequencialmente relacionadas são construídos, tornando tais cenários bastante comuns.

Em termos simples, o problema de maleabilidade da transação ocorre porque o cálculo de ID/hash da transação inclui dados do script de desbloqueio. Intermediários, como nós Bitcoin, podem fazer pequenas modificações no script de desbloqueio, resultando em um ID de transação que não corresponde às expectativas do usuário. Esse problema decorre das primeiras limitações de design no Bitcoin. A atualização do SegWit (Segregated Witness) resolve esse problema desacoplando o ID da transação do script de desbloqueio. Com o SegWit, o cálculo de hash de transação exclui os dados do script de desbloqueio. Os scripts de bloqueio UTXO no SegWit começam com um opcode "OP_0" como marcador, e o script de desbloqueio correspondente é renomeado de SigScript para Witness.

Ao aderir às regras do Segregated Witness (SegWit), a questão da maleabilidade da transação é efetivamente resolvida, eliminando preocupações sobre dados de transação serem manipulados por nós de Bitcoin. A funcionalidade do P2WSH (Pay to Witness Script Hash) é essencialmente a mesma que a do P2SH (Pay to Script Hash). Você pode pré-definir um hash de script no script de bloqueio do UTXO, e a pessoa que enviar o script de desbloqueio fornecerá o conteúdo do script correspondente à cadeia para execução. No entanto, se o conteúdo do script que você precisa for muito grande e contiver muito código, métodos convencionais podem não permitir que você envie o script inteiro para o blockchain do Bitcoin (devido aos limites de tamanho de bloco). Nesses casos, o Taproot entra em ação. O Taproot permite a compressão do conteúdo do script on-chain, tornando possível lidar com scripts maiores. O BitVM aproveita o Taproot para construir soluções mais complexas. No próximo artigo de nossa série “Aproximando-se do BTC”, forneceremos explicações detalhadas sobre Taproot, pré-assinatura e outras tecnologias avançadas relacionadas ao BitVM. Fique ligado!

Isenção de responsabilidade:

1. Este artigo é reproduzido de [ Geek Web3], com direitos autorais pertencentes aos autores originais [Nickqiao & Faust & Shew Wang]. Se houver alguma objeção à reimpressão, entre em contato com o Gate Learnequipe, e a equipe irá processá-la prontamente de acordo com os procedimentos relevantes.
2. Aviso Legal: As visões e opiniões expressas neste artigo são exclusivamente daqueles autores e não constituem nenhum conselho de investimento.
3. Outras versões do artigo foram traduzidas pela equipe Gate Learn. Sem mencionarGate.io, os artigos traduzidos não devem ser copiados, disseminados ou plagiados.