Aproximando-se do BTC: explicação do conhecimento de fundo necessário para o BitVM

Autores: Nickqiao & Faust & Shew Wang, web3 de geeks

Consultor: Equipe de Pesquisa Bitlayer

Resumo:

Recentemente, a Delphi Digital lançou o relatório de pesquisa intitulado ‘The Dawn of Bitcoin Programmability: Paving the Way for Rollups’, que explora a tecnologia de segunda camada do Bitcoin. O relatório detalha os conceitos principais relacionados aos Rollups do Bitcoin, como o conjunto completo de ferramentas BitVM, OP_CAT e cláusulas de restrição de Covenant, camada DA da ecologia do Bitcoin, pontes e as quatro principais camadas secundárias do Bitcoin que utilizam BitVM: Bitlayer, Citrea, Yona e Bob.

Embora o relatório de pesquisa mostre uma visão geral da tecnologia de segunda camada do Bitcoin, ele é bastante geral e carente de descrições detalhadas, o que torna difícil de entender. O Geekweb3 realizou uma exploração mais aprofundada com base no relatório Delphi, tentando permitir que mais pessoas entendam melhor tecnologias como BitVM.

Vamos colaborar com a equipe de pesquisa da Bitlayer e a comunidade chinesa da BitVM para lançar uma série de colunas chamada ‘Aproximando-se do BTC’, que se concentrará em tópicos importantes como BitVM, OP_CAT e pontes de cadeia cruzada do Bitcoin, com o objetivo de popularizar as tecnologias relacionadas à camada 2 do Bitcoin e abrir caminho para mais entusiastas.

Texto:

Há alguns meses, Robin Linus, o líder da ZeroSync, publicou um artigo intitulado “BitVM: Compute Anything on Bitcoin”, que formalmente apresentou o conceito de BitVM e impulsionou o progresso da tecnologia de segunda camada do Bitcoin. Pode-se dizer que esta é uma das inovações mais revolucionárias do ecossistema Bitcoin, que detonou todo o ecossistema de segunda camada do Bitcoin, atraindo a participação de projetos estelares como Bitlayer, Citrea, BOB, entre outros, trazendo vitalidade a todo o mercado.

Posteriormente, mais pesquisadores se envolveram na melhoria do BitVM, lançando sucessivamente diferentes versões iterativas, como BitVM1, BitVM2, BitVMX, BitSNARK, etc. A situação geral é aproximadamente a seguinte:

1. O BitVM implementado por Robin Linus no ano passado, proposto pela primeira vez no White Paper, é conhecido como BitVM0, baseado em um circuito de portas lógicas fictício.
2. Em várias palestras e entrevistas subsequentes, Robin Linus informalmente apresentou o projeto BitVM1, que é baseado em uma CPU fictícia, semelhante ao sistema de prova de fraude Cannon da Optimism. Ele pode simular um efeito de CPU genérica fora da cadeia usando scripts de Bitcoin.
3. Robin Linus também propôs o BitVM2, um protocolo de prova de fraude Permissionless passo a passo não interativo.
4. Os membros da Rootstock Labs e Fairgate Labs lançaram o White Paper do BitVMX, semelhante ao BitVM1, eles esperam simular os efeitos de uma CPU geral usando scripts do Bitcoin (fora da cadeia).

Atualmente, a construção da ecossistema BitVM para os desenvolvedores está cada vez mais clara, a iteração e a melhoria das ferramentas adjacentes também são visíveis a olho nu. Comparado ao ano passado, o ecossistema BitVM agora é ‘levemente visível’ em vez de um ‘castelo no ar’, o que também atrai cada vez mais desenvolvedores e VC para ingressar no ecossistema do Bitcoin.

No entanto, para a maioria das pessoas, entender os termos técnicos relacionados ao BitVM e à camada 2 do Bitcoin não é fácil, porque você precisa primeiro ter uma compreensão sistemática do conhecimento básico ao redor, especialmente o conhecimento de fundo como scripts Bitcoin e Taproot. Os materiais de referência disponíveis na Internet atualmente são ou longos demais e cheios de conversa fiada ou explicados de maneira insuficiente, o que faz com que as pessoas entendam apenas superficialmente. Estamos comprometidos em resolver os problemas acima mencionados e ajudar mais pessoas a entender o conhecimento ao redor da camada 2 do Bitcoin com a maior clareza possível e estabelecer uma compreensão sistemática do sistema BitVM.

MATT e Promessa: O pensamento básico do BitVM

Primeiro, queremos enfatizar que a ideia básica do BitVM é MATT, que significa Merkleize All The Things, referindo-se principalmente ao uso da estrutura de armazenamento de dados em forma de árvore de Merkle para mostrar o processo complexo de execução de programas, tentando tornar a prova de fraude nativa do Bitcoin.

MATT, embora possa expressar uma complexa sequência de operações e rastros de processamento de dados, não irá publicar esses dados diretamente na cadeia BTC, devido ao seu tamanho total extremamente grande. O esquema MATT apenas armazena os dados na árvore Merkle fora da cadeia e publica apenas o resumo do topo da árvore Merkle (Raiz Merkle) na cadeia. Esta árvore Merkle principal contém principalmente três conteúdos principais:

• Código do script de contrato inteligente
• Os dados necessários para o contrato
• Traços deixados pela execução do contrato (registos de alterações na memória, CPU e registos produzidos pela execução do contrato inteligente em máquinas virtuais como EVM)

No plano MATT, apenas a raiz de Merkle de tamanho extremamente pequeno é armazenada na cadeia, e o conjunto completo de dados contidos na árvore de Merkle é armazenado fora da cadeia, o que envolve uma abordagem chamada de ‘compromisso’. Aqui está uma explicação do que é um ‘compromisso’.

Um compromisso é semelhante a uma declaração simplificada, podemos entendê-lo como a ‘impressão digital’ obtida após a compressão de um grande conjunto de dados. Em geral, aqueles que publicam um ‘compromisso’ na cadeia afirmam que certos dados armazenados fora da cadeia são precisos e correspondem a uma declaração simplificada, que é o ‘compromisso’.

Em certos momentos, o hash dos dados pode servir como um ‘compromisso’ para os próprios dados, outros esquemas de compromisso incluem compromisso KZG ou Merkle Tree, etc. Nos protocolos de prova de fraude comumente usados em Layer2, o editor de dados publicará o conjunto completo de dados fora da cadeia e publicará o compromisso dos dados na cadeia. Se alguém descobrir dados inválidos no conjunto de dados fora da cadeia, ele desafiará o compromisso dos dados na cadeia.

Através de compromissos (Commitment), a segunda camada consegue comprimir e processar grandes quantidades de dados, apenas publicando o seu “compromisso” na cadeia Bitcoin. Claro, também é necessário garantir que o conjunto completo de dados publicados fora da cadeia possa ser observado pelo exterior.

Atualmente, várias soluções BitVM, como BitVM0, BitVM1, BitVM2 e BitVMX, adotam estruturas abstratas semelhantes:

1. Decomposição e compromisso do programa: primeiro, o programa complexo é decomposto em um grande número de códigos de operação mais básicos (compilados), e em seguida, os rastros gerados quando esses códigos de operação são executados são registrados (basicamente, é o registro completo das mudanças de estado quando um programa é executado na CPU e na memória, chamado de Trace). Em seguida, organizamos todos os dados, incluindo o Trace e os códigos de operação, em uma coleção de dados e geramos um compromisso para essa coleção de dados.

Os planos de compromisso específicos podem assumir várias formas, tais como: árvores de Merkle, PIOPs (vários algoritmos ZK), funções de hash

2. Stake e Pré-assinatura de Ativos: Os publicadores de dados e os validadores precisam bloquear uma certa quantidade de ativos na cadeia por meio de pré-assinaturas, com restrições específicas. Essas restrições são acionadas de maneira direcionada para possíveis eventos futuros e, caso o publicador de dados se comporte mal, os validadores podem apresentar provas para confiscar os ativos do publicador de dados.

3. Publicação de dados e compromissos: os publicadores de dados publicam compromissos na cadeia, enquanto publicam conjuntos de dados completos fora da cadeia. Os validadores recuperam os conjuntos de dados e verificam se há algum erro. Cada parte do conjunto de dados fora da cadeia está relacionada aos compromissos na cadeia.

4. Desafio e penalização: uma vez que os validadores descobrem que os dados fornecidos pelos publicadores de dados estão incorretos, eles os levarão diretamente para a cadeia para verificação (é preciso dividir esses dados em partes muito pequenas primeiro), esta é a lógica da prova de fraude. Se os resultados da verificação mostrarem que os publicadores de dados forneceram dados inválidos fora da cadeia, seus ativos serão tomados pelos validadores que os desafiaram.

Em resumo, Alice, a provedora de dados, publica todas as trilhas geradas durante a execução das transações de segunda camada fora da cadeia e publica as promessas correspondentes na cadeia. Se você quiser provar que parte dos dados está incorreta, primeiro prove para os nós do Bitcoin que esses dados estão relacionados às promessas na cadeia, ou seja, prove que esses dados foram publicados por Alice. Em seguida, faça os nós do Bitcoin confirmarem que esses dados estão incorretos.

Agora temos uma compreensão geral da ideia por trás do BitVM, e todas as variantes do BitVM estão basicamente dentro desse paradigma. Agora, vamos começar a aprender e entender algumas tecnologias importantes usadas nesse processo, começando pelos scripts do Bitcoin, Taproot e assinaturas prévias.

O que é o script Bitcoin

O conhecimento relacionado ao Bitcoin é mais difícil de entender do que o Ethereum, mesmo a ação mais básica de transferência envolve uma série de conceitos, incluindo UTXO (Saída de transação não gasta), script de bloqueio (também conhecido como PubKey) e script de desbloqueio (também conhecido como Sig). Vamos primeiro explicar esses principais conceitos.

（Um exemplo de código de script Bitcoin composto por operações de código mais baixo nível do que linguagens de programação avançadas）

A forma de expressão de ativos do Ethereum é mais semelhante ao Alipay ou WeChat, onde cada transferência é apenas uma operação de adição ou subtração do saldo em diferentes contas. Esse método tem como foco a conta e o saldo de ativos é apenas um número sob o nome da conta. A forma de expressão de ativos do Bitcoin é mais semelhante ao ouro, onde cada unidade de ouro (UTXO) é marcada com o proprietário. A transferência na verdade é a destruição do UTXO antigo e a geração de um UTXO novo (com alteração do proprietário).

A UTXO do Bitcoin contém dois campos-chave:

Quantidade, em unidades de Satoshi (um BTC é igual a 100 milhões de Satoshi);

O script de bloqueio, também conhecido como “chave pública do script (PubKey)”, define as condições de desbloqueio do UTXO.

É importante notar que a propriedade de todos os UTXOs do Bitcoin é expressa por meio de scripts de bloqueio. Se você quiser transferir seu UTXO para Sam, pode iniciar uma transação para destruir um de seus UTXOs e definir a condição de desbloqueio do novo UTXO como “somente Sam pode desbloquear”.

Depois, se Sam quiser usar esses Bitcoins, ele precisa enviar um script de desbloqueio (Sig), onde Sam precisa mostrar sua assinatura digital para provar que ele é o próprio Sam. Se o script de desbloqueio corresponder ao script de bloqueio mencionado anteriormente, Sam poderá desbloquear e transferir esses Bitcoins para outra pessoa.

（O script de desbloqueio deve corresponder ao script de bloqueio）

Do ponto de vista da forma de expressão, cada transação na cadeia Bitcoin corresponde a vários inputs e outputs, onde cada input declara o UTXO que deseja desbloquear e envia um script de desbloqueio para destruir o UTXO em questão; nos outputs, são exibidas as informações sobre os novos UTXOs gerados, além de revelar o conteúdo do script de bloqueio ao público.

Por exemplo, em um Input de uma transação, você prova ser Sam, desbloqueia várias UTXOs que outras pessoas lhe deram, as destroi e gera várias novas UTXOs, declarando que xxx as desbloqueará no futuro.

Especificamente, nos dados de entrada da transação, você deve declarar quais UTXOs deseja desbloquear e indicar a ‘localização de armazenamento’ desses dados UTXO. Aqui, é importante notar que Bitcoin e Ethereum são completamente diferentes. O Ethereum oferece dois tipos de contas para armazenar dados: contas de contrato e contas EOA. O saldo dos ativos é registrado como números nas contas de contrato ou contas EOA e é unificado e armazenado em um banco de dados chamado ‘estado mundial’. Ao transferir, as modificações são feitas diretamente em contas específicas a partir do ‘estado mundial’, facilitando a localização da posição de armazenamento dos dados.

Bitcoin não tem um design de estado global, os dados de ativos são armazenados de forma dispersa nos blocos anteriores (ou seja, os dados UTXO não gastos são armazenados separadamente em cada saída de transação).

Se quiser desbloquear um determinado UTXO, terá de indicar que as informações desse UTXO estão presentes nos Outputs de uma transação passada, mostrando o ID dessa transação (ou seja, o seu hash) e pedindo ao nó Bitcoin para procurar nos registos históricos. Se quiser verificar o saldo de Bitcoin de um determinado endereço, terá de percorrer todos os blocos desde o início, para encontrar os UTXOs não desbloqueados associados ao endereço xx.

Ao usar uma carteira de Bitcoin no dia a dia, você pode verificar rapidamente o saldo de Bitcoin de um determinado endereço. Muitas vezes, isso ocorre porque o serviço da carteira escaneia os blocos e indexa todos os endereços, o que nos permite fazer consultas rápidas.

Ao gerar uma declaração de transação para enviar seus UTXOs para outra pessoa, é necessário marcar a posição desses UTXOs no histórico de transações do Bitcoin com base no hash/ID da transação a que eles pertencem.

Interessante é que o resultado da transação de Bitcoin é calculado fora da cadeia, quando o usuário gera a transação no dispositivo local, ele precisa criar diretamente todas as entradas e saídas, o que é equivalente a calcular completamente o resultado da transação. A transação é transmitida para a rede Bitcoin e só é incluída na cadeia após ser validada pelos nós. Este modelo de “cálculo fora da cadeia - validação na cadeia” é completamente diferente do Ethereum, onde você só precisa fornecer os parâmetros de entrada da transação, e o resultado da transação é calculado e produzido pelos nós Ethereum.

Além disso, o script de bloqueio (Locking) do UTXO pode ser personalizado, você pode definir o UTXO como ‘desbloqueável pelo proprietário de um determinado endereço BTC’, onde o proprietário do endereço precisa fornecer uma assinatura digital e uma chave pública (P2PKH). No tipo de transação Pay-to-Hash (P2SH), você pode adicionar um hash ao script de bloqueio UTXO, e quem puder apresentar o preimage do hash correspondente e cumprir as condições predefinidas no preimage, poderá desbloquear o UTXO. O script Taproot usado pelo BitVM tem características semelhantes ao P2SH.

Como desencadear um script de Bitcoin

Aqui vamos primeiro usar P2PKH como exemplo para explicar o método de ativação do script do Bitcoin. Apenas entendendo o método de ativação é possível compreender o Taproot e o BitVM, que são mais complexos. P2PKH significa “Pagar para o Hash da Chave Pública”. Neste esquema, o script de bloqueio da UTXO define um hash de chave pública, e ao desbloquear, é necessário fornecer a chave pública correspondente a esse hash, o que é basicamente semelhante à ideia convencional de transferência de Bitcoin.

Neste momento, os nós do Bitcoin devem confirmar se a chave pública no script de desbloqueio corresponde ao hash da chave pública especificado no script de bloqueio, ou seja, confirmar se a chave submetida pela pessoa que desbloqueia corresponde à chave pré-definida pelo UTXO que está bloqueado.

Além disso, no esquema P2PKH, quando um nó Bitcoin recebe uma transação, ele combina o script de desbloqueio Sig fornecido pelo usuário com o script de bloqueio Pubkey do UTXO a ser desbloqueado e os executa no ambiente de execução do script BTC. A imagem abaixo mostra o resultado da concatenação antes da execução:

Os leitores podem não estar familiarizados com o ambiente de execução de scripts BTC, então vamos fazer uma breve introdução aqui. Em primeiro lugar, o script BTC contém dois elementos:

Os dados e os códigos de operação. Estes dados e códigos de operação são empurrados para a pilha em ordem da esquerda para a direita e executados de acordo com a lógica especificada, obtendo o resultado final (sobre o que é uma pilha, não vamos entrar em detalhes aqui; os leitores podem consultar o ChatGPT por conta própria).

No exemplo acima, à esquerda está a assinatura digital e a chave pública incluídas no script de desbloqueio Sig enviadas por alguém, enquanto à direita, no script de bloqueio Pubkey, estão contidos códigos de operação e dados definidos pelo criador do UTXO ao criar o UTXO (não é necessário compreender o significado de cada código de operação, apenas ter uma compreensão geral).

Os códigos de operação DUP, HASH160, EQUALVERIFY, etc. na script de bloqueio do lado direito da figura são responsáveis por tomar o Public key carregado no script de desbloqueio do lado esquerdo, obter o hash e compará-lo com o hash de Public key predefinido no script de bloqueio. Se os dois forem iguais, significa que a chave pública enviada no script de desbloqueio corresponde ao hash de chave pública predefinido no script de bloqueio, passando assim na primeira verificação.

No entanto, há um problema, o conteúdo do script de bloqueio UTXO é na cadeia pública, onde qualquer pessoa pode observar o hash da chave pública incluída e qualquer um pode fazer o upload da chave pública correspondente, alegando ser a pessoa ‘designada’. Portanto, após verificar a chave pública e o hash da chave pública, é necessário verificar se o remetente da transação é realmente o controlador real da chave pública, para o qual é necessário verificar a assinatura digital. O código de operação CHECKSIG no script de bloqueio é responsável por verificar a assinatura digital.

Resumindo, no esquema P2PKH, o script de desbloqueio enviado pelo remetente da transação contém a chave pública e a assinatura digital. Essa chave pública deve corresponder ao hash da chave pública especificado no script de bloqueio e a assinatura digital da transação deve estar correta. Somente quando essas condições forem atendidas, o UTXO pode ser desbloqueado com sucesso.

(Esta imagem é dinâmica: diagrama esquemático do script de desbloqueio do Bitcoin sob o esquema P2PKH

Fonte: ** )

Claro, a rede Bitcoin suporta vários tipos de transações, não apenas Pay to public key/public key hash, mas também P2SH (Pay to hash) e outros, tudo depende de como o script de bloqueio personalizado é definido ao criar a UTXO.

Aqui, é importante notar que, no esquema P2SH, um hash pode ser pré-definido no script de bloqueio e o script de desbloqueio precisa enviar o conteúdo completo do script correspondente ao hash. Os nós do Bitcoin podem executar esse script e, se ele definir a lógica de verificação de várias assinaturas, pode-se obter o efeito de uma carteira com várias assinaturas na cadeia do Bitcoin.

Claro, no esquema P2SH, o criador do UTXO deve informar antecipadamente a pessoa que desbloqueará o UTXO sobre o conteúdo do script correspondente ao hash. Se ambas as partes conhecem o conteúdo, podemos implementar lógicas de negócios mais complexas do que a assinatura múltipla.

Aqui é importante esclarecer que a cadeia de Bitcoin (bloco) não registra diretamente quais UTXO e quais endereços estão associados. Ela apenas registra qual UTXO pode ser desbloqueado pelo hash da chave pública/hash do script, mas podemos calcular rapidamente o endereço correspondente com base no hash da chave pública/hashed do script (aquela parte que parece um código de barras na interface da carteira).

A razão pela qual podemos ver na interface do explorador de blocos e da carteira que o endereço xx tem uma quantidade de bitcoin xx é porque o explorador de blocos e o projeto da carteira ajudam a analisar esses dados para você. Eles escaneiam todos os blocos e, com base no hash público/criptográfico declarado no script de bloqueio, calculam o correspondente ‘endereço’ e mostram quantos bitcoins estão no endereço xx.

SegWit e Witness

Quando entendemos a ideia do P2SH, ficamos mais próximos do Taproot, no qual o BitVM depende. Mas antes disso, precisamos entender um conceito importante: Witness e SegWit.

Ao revisar os scripts de desbloqueio e bloqueio mencionados anteriormente, bem como o processo de desbloqueio UTXO, surge um problema: a assinatura digital da transação está incluída no script de desbloqueio, e ao gerar a assinatura, não é possível cobrir o script de desbloqueio (os parâmetros usados para gerar a assinatura não podem incluir a assinatura em si), portanto, a assinatura digital só pode cobrir a parte fora do script de desbloqueio, ou seja, só pode se relacionar com a parte principal dos dados da transação e não pode cobrir completamente os dados da transação.

Desta forma, mesmo que o script de desbloqueio da transação seja manipulado pelo intermediário, isso não afetará o resultado da verificação. Por exemplo, um nó Bitcoin ou um pool de mineração pode inserir outros dados no script de desbloqueio da transação, fazendo com que os dados da transação sofram alterações sutis sem afetar a verificação e o resultado da transação, resultando em uma mudança no hash/ID da transação calculado. Isso é conhecido como o problema da maleabilidade da transação.

A desvantagem disso é que, se você pretende realizar várias transações consecutivas e elas têm uma dependência sequencial (por exemplo, a transação 3 faz referência à saída da transação 2, a transação 2 faz referência à saída da transação 1), as transações posteriores devem referenciar o ID (hash) das transações anteriores. Piscinas de mineração ou quaisquer intermediários podem ajustar levemente o conteúdo do script de desbloqueio, fazendo com que o hash da transação após a cadeia seja diferente do que você esperava, resultando na invalidação das múltiplas transações ordenadas que você criou previamente.

Na verdade, nos casos do DLC Bridge e do BitVM2, são construídas transações em lote com uma ordem sequencial, o que torna os cenários mencionados anteriormente bastante comuns.

Em termos simples, o problema da escalabilidade das transações ocorre porque o ID/hash da transação inclui os dados do script de desbloqueio durante o cálculo, e os intermediários, como os nós de Bitcoin, podem ajustar ligeiramente o conteúdo do script de desbloqueio, resultando em um ID de transação que não corresponde às expectativas do utilizador. Na verdade, este é um fardo histórico deixado para trás devido a considerações imperfeitas no design inicial do Bitcoin.

A atualização SegWit lançada posteriormente é, na verdade, a separação completa da ID da transação e do script de desbloqueio, não sendo necessário incluir os dados do script de desbloqueio ao calcular o hash da transação. O script de bloqueio UTXO que segue a atualização SegWit é automaticamente configurado com um código de operação chamado “OP_0” no início, atuando como uma marca; enquanto o script de desbloqueio correspondente foi renomeado de Sig para Witness (testemunha).

Ao seguir as regras de Testemunha Segregada, problemas de escalabilidade de transações serão adequadamente resolvidos, você não precisa se preocupar com dados de transações enviados para nós de nós Bitcoin sendo manipulados. É claro que não precisamos tornar as coisas muito complicadas, a funcionalidade P2WSH não é essencialmente diferente da P2SH discutida anteriormente. Você pode pré-definir um hash de script em um script de bloqueio UTXO, e quando o remetente do script de desbloqueio enviar o conteúdo do script correspondente ao hash para a cadeia e executá-lo.

Mas se o script que você deseja implementar for especialmente longo, contendo muitas linhas de código, não é possível submeter o script completo à cadeia de Bitcoin de forma convencional (cada bloco tem um limite de tamanho). O que fazer? É aqui que entra o Taproot, para simplificar o conteúdo do script a ser submetido à cadeia, e o BitVM é exatamente a solução complexa baseada no Taproot.