Resumo:

A Delphi Digital lançou recentemente um relatório intitulado "O Amanhecer da Programabilidade do Bitcoin: Abrindo Caminho para Rollups", que delineia conceitos-chave relacionados aos Rollups de Bitcoin, incluindo a suite 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 de Camada 2 do Bitcoin, permanece bastante geral e carece de descrições detalhadas, tornando-o um pouco difícil de compreender. 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 da 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 cruzadas do Bitcoin, com o objetivo de desmistificar as tecnologias da Camada 2 do Bitcoin para um público mais amplo e abrir caminho para mais entusiastas.

Há alguns meses, 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 um interesse significativo e atividade 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 é a seguinte:

1. Robin Linus apresentou inicialmente o white paper de implementação do BitVM no ano passado, que é baseado em um circuito de portão lógico conceitual e é conhecido como BitVM0.
2. Nas 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 Bitcoin.
3. Robin Linus também propôs BitVM2, um protocolo de prova de fraude não interativa de um único passo sem permissão.
4. Membros da Rootstock Labs e da Fairgate Labs lançaram um white paper sobre BitVMX. Semelhante ao BitVM1, eles visam 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 tem atraído cada vez mais pessoas. Mais desenvolvedores e VCs estão se lançando no ecossistema Bitcoin.

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

MATT e Compromissos: O Conceito Central do BitVM

O conceito central do BitVM gira em torno do 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. O 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 registros de CPU durante a execução de contratos inteligentes em máquinas virtuais como EVM)

(Um diagrama esquemático simples de Á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 âmbito do 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. Isto utiliza 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 comprimir 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” para os dados em si. Outros esquemas de compromisso incluem o compromisso KZG ou Árvore de Merkle. No protocolo usual da prova de fraude da Camada2, o editor de dados publicará o conjunto de dados completo off-chain e um compromisso de publicar o conjunto de dados on-chain. Se alguém descobrir dados inválidos no conjunto de dados off-chain, o compromisso de dados on-chain será contestado.

Através do compromisso, a segunda camada pode comprimir uma grande quantidade de dados e apenas publicar seu "compromisso" na cadeia de Bitcoin. Claro, também é necessário garantir que o conjunto de dados completo divulgado 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 de Programa e Compromisso: Inicialmente, um programa complexo é decomposto em numerosos opcodes básicos (compilação). Os rastros de execução desses opcodes (essencialmente as mudanças de estado quando um programa é executado na CPU e memória, conhecido como Rastreamento) são gravados. Todos os dados, incluindo o Rastreamento e 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 e verificador de dados devem bloquear uma certa quantidade de ativos na blockchain através 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 maliciosamente, o verificador pode apresentar prova e tomar os ativos do editor de dados.
3. Publicação de Dados e Compromisso: O editor de dados publica o compromisso na cadeia e o conjunto de dados completo fora da cadeia. O verificador recupera e verifica o conjunto de dados em busca de erros. Cada parte do conjunto de dados fora da cadeia está ligada ao compromisso na cadeia.
4. Desafio e Penalidade: Se o verificador encontrar erros nos dados fornecidos pelo editor de dados, este leva esta parte dos dados para a cadeia 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 desafiador. Em resumo, o editor de dados, Alice, divulga todos os vestígios gerados durante a execução das transações da Camada 2 fora da cadeia e publica o compromisso correspondente na cadeia. Para provar que uma parte dos dados está incorreta, primeiro é necessário mostrar ao nó Bitcoin que esses dados se relacionam com o compromisso na cadeia, confirmando que foi divulgado por Alice, e depois o nó Bitcoin verifica a precisão dos dados. Tendo compreendido a ideia geral do BitVM, todas as variantes do BitVM aderem a esse paradigma básico. A seguir, iremos aprofundar algumas das principais tecnologias usadas nesse processo, começando pelos fundamentos dos scripts do Bitcoin, Taproot e pré-assinaturas.

O que é o Bitcoin Script?

Compreender o Bitcoin pode ser mais desafiante do que o Ethereum, pois até 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.

(Uma amostra 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 como apenas números associados a contas. Em contraste, a representação de ativos do Bitcoin é mais como lidar com ouro, onde cada pedaço de ouro (UTXO) é marcado com um proprietário. Uma transação 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-chave:

• Quantidade: Medido em “satoshis” (um BTC equivale a cem milhões de satoshis);
• Script de Bloqueio (ScriptPubKey): Isto define as condições necessárias para desbloquear o UTXO. A propriedade do UTXO do Bitcoin é determinada pelo script de bloqueio. Por exemplo, se desejar transferir o seu UTXO para o Sam, deve iniciar uma transação que destrói o seu UTXO e cria um novo com a condição “apenas o Sam pode desbloquear”. Quando o Sam quiser usar estes bitcoins, tem de submeter um script de desbloqueio (ScriptSig). Neste script, o Sam fornece a sua assinatura digital para provar a sua identidade. Se o script de desbloqueio corresponder ao script de bloqueio original, o 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 um UTXO a desbloquear e fornece um script de desbloqueio para o fazer, que então desbloqueia e destrói o UTXO. As saídas da transação mostram os UTXOs recém-criados e exibem publicamente os scripts de bloqueio associados. Por exemplo, numa entrada da transação, você prova que é Sam desbloqueando múltiplos UTXOs que outros lhe enviaram, destruindo-os no processo. Em seguida, você cria vários novos UTXOs e especifica que xxx pode desbloqueá-los 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 forma diferente. O Ethereum usa contas de contrato e Contas de Propriedade Externa (EOAs) para armazenar dados, com saldos de ativos registrados como números nessas contas. Todas essas informações são armazenadas em um banco de dados chamado "estado do mundo". Quando uma transação ocorre, o "estado do mundo" atualiza diretamente os saldos de contas específicas, facilitando a localização dos dados. Em contraste, o Bitcoin não possui um "estado do mundo". Em vez disso, os dados de ativos são distribuídos pelos blocos anteriores como UTXOs não gastos, armazenados individualmente na Saída de cada transação.

Se desejar desbloquear um determinado UTXO, é necessário indicar em que Transação Output a informação UTXO existe no passado e mostrar o ID da transação (que é o seu hash). Permita que o nó Bitcoin procure-o no histórico. Se desejar consultar o saldo de Bitcoin de um determinado endereço, é necessário percorrer todos os blocos desde o início para encontrar o UTXO desbloqueado associado ao endereço xx.

Quando costuma usar uma carteira Bitcoin, pode verificar rapidamente o saldo de Bitcoin possuído por um determinado endereço. Isto acontece frequentemente porque o próprio serviço de carteira indexa todos os endereços, digitalizando blocos, o que torna mais fácil para nós consultar rapidamente.

(Quando cria uma transação para transferir o seu UTXO para outra pessoa, precisa de especificar a localização desse UTXO no histórico de transações do Bitcoin, fazendo referência ao hash/ID da transação à qual pertence.) Curiosamente, os resultados das transações de Bitcoin são calculados off-chain. Quando os utilizadores geram transações nos seus dispositivos locais, devem criar todos os Inputs e Outputs antecipadamente, calculando efetivamente os outputs da transação. A transação é então transmitida para a rede Bitcoin, verificada pelos nós e adicionada à blockchain. Este modelo de “cálculo off-chain — verificação on-chain” é totalmente diferente do Ethereum. No Ethereum, só precisa de fornecer os parâmetros de entrada da transação, e os resultados da transação são calculados e output pelos nós do Ethereum. Além disso, o script de bloqueio de um UTXO pode ser personalizado. Pode definir um UTXO para ser “desbloqueável pelo proprietário de um endereço Bitcoin específico,” exigindo que o proprietário forneça uma assinatura digital e uma chave pública (P2PKH). Nas transações Pay-to-Script-Hash (P2SH), pode adicionar um Script Hash ao script de bloqueio do UTXO. Qualquer pessoa que possa submeter o script correspondente a este hash e cumprir as condições especificadas no script pode desbloquear o UTXO. O script Taproot, em que BitVM se baseia, utiliza funcionalidades semelhantes às do P2SH.

Como acionar o script Bitcoin

Para entender o mecanismo de acionamento dos scripts do Bitcoin, começaremos com o exemplo P2PKH, que significa "Pagar para Hash da Chave Pública". Nesta configuração, o script de bloqueio de um UTXO contém um hash da chave pública e, para desbloqueá-lo, a chave pública correspondente deve ser fornecida. Este mecanismo está alinhado com o processo padrão das transações de Bitcoin. Neste contexto, um nó do Bitcoin deve verificar se a chave pública no script de desbloqueio corresponde ao hash da chave pública especificado no script de bloqueio. Essencialmente, verifica se a "chave" fornecida pelo usuário corresponde à "fechadura" definida pelo UTXO. Em mais detalhes, sob o esquema P2PKH, quando um nó do Bitcoin recebe uma transação, 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, hash a chave pública do script de desbloqueio do lado esquerdo e comparam-na com o hash de chave pública predefinido no script de bloqueio. Se corresponderem, confirma que a chave pública no script de desbloqueio corresponde ao hash da chave pública no script de bloqueio, passando pela primeira verificação. No entanto, há um problema: o conteúdo do script de bloqueio é publicamente visível no blockchain, o que significa que qualquer pessoa pode ver o hash da chave pública. Portanto, qualquer pessoa pode 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 da 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 lida com essa verificação. Em resumo, sob o esquema P2PKH, o script de desbloqueio do iniciador de transações 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 de Bitcoin sob o esquema P2PKH
Origem: 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ó do Bitcoin pode então executar este script e, se incluir lógica de verificação de multi-assinatura, efetivamente permite carteiras de multi-assinatura na blockchain do Bitcoin. No esquema P2SH, o criador do UTXO precisa informar a pessoa que desbloqueará o 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 multi-assinatura. 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 rapidamente derivar o endereço correspondente (a sequência de caracteres que parece um absurdo exibido nas interfaces da carteira) do hash de chave pública ou hash de script.

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

Testemunha Segregada e Testemunha

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

Consequentemente, a assinatura digital só pode cobrir partes dos dados da transação fora do script de desbloqueio, ou seja, não pode proteger totalmente todos os dados da transação. Isso leva a uma vulnerabilidade onde um intermediário pode modificar ligeiramente o script de desbloqueio sem afetar a verificação da assinatura. Por exemplo, nós de Bitcoin ou grupos de mineração poderiam 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 da transação/ID da transação calculado. Este problema é conhecido como maleabilidade da transação.

O problema é que se planeia iniciar várias transações sequenciais que dependem umas das outras (por exemplo, a transação 3 faz referência à saída da transação 2 e a transação 2 faz referência à saída da transação 1), as transações subsequentes devem fazer referência aos hashes das transações anteriores. Qualquer intermediário, como um pool de mineração ou nó Bitcoin, pode fazer ligeiras modificações no script de desbloqueio, fazendo com que o hash da transação difira da sua expectativa uma vez que está na blockchain.

Esta discrepância pode invalidar a sua sequência pré-planeada de transações interdependentes. Este problema é particularmente relevante no contexto das pontes 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. Este problema decorre das primeiras limitações de design no Bitcoin. A atualização Segregated Witness (SegWit) 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 de script de desbloqueio. Os scripts de bloqueio UTXO em SegWit começam com um opcode "OP_0" como um 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 com a possibilidade de os dados da transação serem adulterados 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). É possível pré-definir um hash de script no script de bloqueio UTXO, e a pessoa que submeter 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 da nossa série “Aproximando-se do BTC”, forneceremos explicações detalhadas sobre o Taproot, pré-assinatura e outras tecnologias avançadas relacionadas ao BitVM. Fique atento!

Aviso legal:

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