1. Introdução

O Bitcoin é um ativo digital descentralizado, seguro e confiável. No entanto, enfrenta limitações significativas que o impedem de se tornar uma rede escalável para pagamentos e outras aplicações. A questão da escalabilidade do Bitcoin tem sido uma preocupação desde o seu início. O modelo UTXO (Unspent Transaction Output) do Bitcoin trata cada transação como um evento independente, levando a um sistema sem estado que carece da capacidade de executar cálculos complexos dependentes do estado. Como resultado, enquanto o Bitcoin pode realizar scripts simples e transações multiassinatura, ele enfrenta dificuldades para facilitar as interações contratuais complexas e dinâmicas comuns em plataformas blockchain com estado. Essa limitação restringe significativamente o alcance de aplicativos descentralizados (dApps) e instrumentos financeiros complexos que podem ser construídos no Bitcoin, enquanto os modelos de plataforma com estado oferecem um ambiente mais diversificado para implantar e executar contratos inteligentes ricos em recursos.

Para a escalabilidade do Bitcoin, as principais tecnologias incluem canais de estado, sidechains e validação do lado do cliente. Os canais de estado oferecem uma solução de pagamento segura e diversificada, mas têm capacidade limitada para verificar cálculos arbitrariamente complexos. Essa limitação reduz sua aplicabilidade em vários cenários que requerem lógica e interações complexas condicionais. As sidechains suportam uma ampla gama de aplicações e oferecem diversidade além das capacidades do Bitcoin, mas possuem segurança inferior. Essa diferença de segurança decorre do uso de mecanismos de consenso independentes pelas sidechains, que são muito menos robustos do que o mecanismo de consenso do Bitcoin. A validação do lado do cliente, usando o modelo UTXO do Bitcoin, pode lidar com transações mais complexas, mas carece de verificação bidirecional e restrições com o Bitcoin, levando a uma segurança inferior. O design off-chain dos protocolos de validação do lado do cliente depende de servidores ou infraestrutura de nuvem, o que poderia levar à centralização ou censura potencial por meio de servidores comprometidos. O design off-chain da validação do lado do cliente também introduz mais complexidade na infraestrutura da blockchain, possivelmente levando a problemas de escalabilidade.

Em dezembro de 2023, Robin Linus, o líder do projeto ZeroSync, publicou um white paper intitulado “BitVM: Compute Anything On Bitcoin”, o que suscitou considerável reflexão sobre o aprimoramento da programabilidade do Bitcoin. O artigo propõe uma solução de contrato Bitcoin completa de Turing que pode executar qualquer computação complexa no Bitcoin sem alterar as regras de consenso da rede ou modificar os princípios fundamentais do Bitcoin. O BitVM aproveita scripts do Bitcoin e Taproot para implementar Rollups otimistas. Ele usa assinaturas de Lamport (também conhecidas como compromisso de bit) para estabelecer conexões entre dois UTXOs do Bitcoin, possibilitando scripts stateful do Bitcoin. Um programa extenso é comprometido dentro de um endereço Taproot, e operadores e validadores participam de extensas interações fora da cadeia, deixando uma pegada mínima no blockchain. Se ambas as partes cooperarem, qualquer computação complexa e stateful fora da cadeia pode ser executada sem deixar rastro no blockchain. No entanto, se as partes não cooperarem, a execução na cadeia é necessária em caso de disputa. Portanto, o BitVM expande significativamente os casos de uso potencial do Bitcoin, permitindo que ele sirva não apenas como uma moeda, mas também como uma plataforma de verificação para várias aplicações descentralizadas e tarefas computacionais complexas.

No entanto, apesar das vantagens da tecnologia BitVM na escalabilidade do Bitcoin, ainda está em estágios iniciais e enfrenta alguns problemas de eficiência e segurança, como: (1) Os desafios e respostas exigem múltiplas interações, resultando em altas taxas de transação e períodos de desafio demorados; (2) As assinaturas únicas de Lamport têm comprimentos longos de dados, exigindo uma redução no tamanho dos dados; (3) A complexidade da função hash requer funções hash amigáveis ao Bitcoin para reduzir os custos; (4) Os contratos BitVM existentes são grandes, e a capacidade do bloco Bitcoin é limitada, então usar scripts sem script poderia ajudar a alcançar o BitVM de Scripts sem Script, economizando espaço de bloco Bitcoin e aprimorando a eficiência do BitVM; (5) O BitVM atual opera em um modelo de permissão, com desafios iniciados apenas pelos membros do consórcio e limitados a duas partes, o que deve ser expandido para um modelo de desafio multi-partes sem permissão para reduzir ainda mais as suposições de confiança. Para resolver esses problemas, o artigo sugere várias ideias de otimização para melhorar a eficiência e a segurança do BitVM.

2. Princípio BitVM

BitVM é posicionado como um sistema de contrato off-chain para Bitcoin, com o objetivo de avançar a funcionalidade de contrato do Bitcoin. Atualmente, os scripts do Bitcoin são totalmente sem estado, o que significa que o ambiente de execução é redefinido após cada script. Não há uma maneira nativa no script do Bitcoin para garantir que os scripts 1 e 2 tenham o mesmo valor de x. No entanto, é possível tornar os scripts do Bitcoin stateful usando opcodes existentes e assinaturas de uma única vez de Lamport, garantindo que x no script1 e script2 sejam iguais. Se os participantes assinarem valores de x conflitantes, eles podem ser penalizados.

As computações BitVM ocorrem off-chain, enquanto a verificação dessas computações ocorre on-chain. Dado o limite de 1MB dos blocos Bitcoin, quando a verificação de computações complexas é necessária, a tecnologia OP pode ser usada no modo de desafio-resposta para suportar uma verificação de computação de maior complexidade.

Similar ao Optimistic Rollup e à proposta MATT (Merkelize All The Things), o sistema BitVM é baseado em provas de fraude e protocolos de desafio-resposta, mas não requer alterações nas regras de consenso do Bitcoin. Os primitivos subjacentes do BitVM são simples, baseados principalmente em hash locks, time locks e grandes árvores Taproot.

Provadores se comprometem com o programa byte a byte, mas verificar todas as computações on-chain seria proibitivamente caro. Portanto, os verificadores realizam uma série de desafios cuidadosamente elaborados para refutar sucintamente as alegações falsas do provador. Provadores e verificadores coassinam uma série de transações de desafio e resposta para resolver disputas, permitindo a verificação de computação geral no Bitcoin.

Os principais componentes do BitVM incluem:

• Compromisso de circuito: Os provadores e verificadores compilam o programa em um circuito binário grande. O provador se compromete com este circuito em um endereço Taproot, com cada script de folha sob esse endereço correspondendo a cada porta lógica no circuito. O núcleo é alcançar o compromisso da porta lógica com base no compromisso do bit.
• Desafio e resposta: Os provadores e verificadores pré-assinam uma série de transações para implementar o jogo de desafio-resposta. Idealmente, essa interação ocorre fora da cadeia, mas também pode ser executada na cadeia se o provador for incooperativo.
• Penalidade ambígua: Se o provador fizer reivindicações incorretas, o verificador pode tomar o depósito do provador após desafiar com sucesso e frustrar as ações maliciosas do provador.

3. Otimizações BitVM

3.1 Reduzir o número de interações OP com base em ZK

Existem dois tipos principais de Rollups: ZK Rollups e Optimistic Rollups (OP Rollups). ZK Rollups dependem da verificação de validade de Provas de Conhecimento Zero (ZK), que são provas criptográficas de execução correta. Sua segurança depende de suposições de complexidade computacional. Optimistic Rollups dependem de Provas de Fraude, presumindo que todos os estados enviados estão corretos e geralmente estabelecendo um período de desafio de cerca de sete dias. Sua segurança pressupõe que pelo menos uma parte honesta no sistema pode detectar o estado incorreto e enviar uma prova de fraude.

Supondo que o número máximo de etapas para o programa de desafio do BitVM seja 2^32, ele precisaria de aproximadamente 17GB de memória (2^32 × 4 bytes). No pior cenário, cerca de 40 rodadas de desafios e respostas podem levar cerca de seis meses, com um tamanho total de script de cerca de 150KB. Esse cenário forneceria incentivos insuficientes, mas raramente ocorre na prática.

Usar Provas de Conhecimento Zero para reduzir o número de desafios no BitVM poderia aumentar sua eficiência. Segundo a teoria da Prova de Conhecimento Zero, se os dados satisfazem um algoritmo F, então a prova satisfaz o algoritmo de verificação Verify, produzindo Verdadeiro. Por outro lado, se os dados não satisfazem F, então a prova não satisfará Verify, produzindo Falso. No sistema BitVM, se o desafiante não aceitar os dados do comprovante, um desafio é iniciado.

Para o algoritmo F, usando uma abordagem de pesquisa binária, assumindo que são necessárias 2^n iterações para encontrar o ponto de erro. Se a complexidade do algoritmo for muito alta, n for grande e levar muito tempo para ser concluído. No entanto, a complexidade do algoritmo de verificação de Prova de Conhecimento Zero Verify é fixa. Ao revelar publicamente a prova e o processo de verificação Verify, é possível ver uma saída de Falso. A vantagem das Provas de Conhecimento Zero está na menor complexidade computacional necessária para abrir o algoritmo de verificação Verify em comparação com a abertura do algoritmo original F usando pesquisa binária. Assim, com as Provas de Conhecimento Zero, o BitVM não desafia mais o algoritmo original F, mas sim o algoritmo de verificação Verify, reduzindo o número de rodadas de desafio e encurtando o período de desafio.

Embora a validade das Provas de Conhecimento Zero e Provas de Fraude dependa de diferentes pressupostos de segurança, elas podem ser combinadas para construir uma Prova de Fraude de ZK e implementar uma Prova de ZK sob Demanda. Ao contrário de um ZK Rollup completo, o modelo sob Demanda requer uma Prova de ZK apenas quando um desafio é feito, mantendo um design otimista onde o estado gerado é assumido como válido até ser desafiado. Se um estado não é desafiado, nenhuma Prova de ZK é necessária. No entanto, se um desafio é feito, uma Prova de ZK deve ser gerada para a correção de todas as transações dentro do bloco desafiado. No futuro, poderá ser possível gerar Provas de Fraude de ZK para instruções disputadas individualmente, evitando o custo computacional de gerar continuamente Provas de ZK.

3.2 assinaturas únicas amigáveis ao Bitcoin

Na rede Bitcoin, transações que seguem as regras de consenso são consideradas válidas, mas além dessas regras, existe um conceito adicional de padronização. Os nós do Bitcoin apenas propagam e transmitem transações padrão, e a única maneira de transações válidas mas não padrão serem incluídas em um bloco é através de colaboração direta com os mineradores.

De acordo com as regras de consenso, o tamanho máximo para transações legadas (não-Segwit) é de 1MB, o que poderia preencher um bloco inteiro. No entanto, o limite de normalidade para transações legadas é definido em 100kB. Para transações Segwit, o tamanho máximo permitido pelas regras de consenso é de 4MB, conhecido como limite de peso, mas seu limite de normalidade é de 400kB.

As assinaturas de Lamport são um componente fundamental do BitVM e a redução do comprimento das assinaturas e chaves públicas ajuda a diminuir o tamanho dos dados da transação, reduzindo assim as taxas de transação. As assinaturas únicas de Lamport requerem uma função de hash (como uma função de permutação unidirecional f). Em um esquema de assinatura única de Lamport, o comprimento da mensagem é de v bits, e tanto a chave pública quanto o comprimento da assinatura são de 2v bits. Essas longas assinaturas e chaves públicas consomem uma quantidade significativa de gás de armazenamento. Portanto, é necessário explorar esquemas de assinatura que possam reduzir o comprimento das assinaturas e chaves públicas. Em comparação com as assinaturas únicas de Lamport, as assinaturas únicas de Winternitz reduzem significativamente os comprimentos das assinaturas e chaves públicas, mas aumentam a complexidade computacional de assinatura e verificação.

No esquema de assinatura única de Winternitz, uma função especial P mapeia uma mensagem de v bits para um vetor s de comprimento n, sendo que cada elemento de s assume um valor em {0,…,d}. O esquema de assinatura única de Lamport é um caso especial do esquema de Winternitz, onde d=1. No esquema de Winternitz, a relação entre n, d e v é aproximadamente n≈v/log2(d+1). Quando d=15, n≈(v/4)+1. Para uma assinatura de Winternitz com n elementos, os comprimentos da chave pública e da assinatura são quatro vezes mais curtos do que aqueles no esquema de assinatura única de Lamport, mas a complexidade da verificação é quatro vezes maior. Usar d=15, v=160, f=ripemd160(x) no BitVM para assinaturas únicas de Winternitz pode reduzir o tamanho do compromisso de bits em 50%, reduzindo assim as taxas de transação do BitVM em pelo menos 50%. No futuro, ao otimizar a implementação do script Bitcoin de Winternitz existente, a exploração de esquemas de assinatura única mais compactos expressáveis no script Bitcoin poderia ser perseguida.

3.3 Funções de Hash Amigáveis ao Bitcoin

De acordo com as regras de consenso, o tamanho máximo para um script P2TR é de 10kB, e o tamanho máximo para uma testemunha de script P2TR é o mesmo que o tamanho máximo de transação Segwit, que é 4MB. No entanto, o limite de normalidade para uma testemunha de script P2TR é de 400kB.

Atualmente, a rede Bitcoin não suporta OP_CAT, o que torna impossível concatenar strings para verificação do caminho de Merkle. Portanto, há a necessidade de implementar uma função hash amigável ao Bitcoin usando o script Bitcoin existente, da maneira mais eficiente em termos de tamanho tanto para o tamanho do script quanto o tamanho da testemunha do script, para suportar a verificação da prova de inclusão de Merkle.

BLAKE3 é uma versão otimizada da função de hash BLAKE2 e introduz um modo de árvore Bao. Comparado ao baseado em BLAKE2s, a quantidade de rodadas da função de compressão foi reduzida de 10 para 7. A função de hash BLAKE3 divide sua entrada em pedaços de 1024 bytes, sendo o último pedaço possivelmente mais curto, mas não vazio. Quando há apenas um pedaço, ele serve como nó raiz e único nó da árvore. Esses pedaços são arranjados como nós folha de uma árvore binária, e cada pedaço é comprimido de forma independente.

Quando o BitVM é usado para verificar provas de inclusão de Merkle, a entrada para a operação de hash consiste em dois valores de hash de 256 bits concatenados, totalizando 64 bytes. Com a função de hash BLAKE3, esses 64 bytes podem caber em um único bloco, o que significa que a operação de hash BLAKE3 só precisa aplicar a função de compressão uma vez a este único bloco. Na função de compressão do BLAKE3, sete funções de rodada e seis funções de permutação são necessárias.

O BitVM já implementou operações básicas como XOR, adição modular e deslocamento de bit à direita com base em valores u32, tornando simples montar uma função de hash BLAKE3 usando script do Bitcoin. A pilha usa quatro bytes separados para representar palavras u32, facilitando a adição u32, XOR bit a bit u32 e rotações bit a bit u32 necessárias para o BLAKE3. A função de hash BLAKE3 no script do Bitcoin tem atualmente cerca de 100kB, suficiente para construir uma versão simplificada do BitVM.

Além disso, ao dividir esses códigos BLAKE3, o Verificador e o Provador podem reduzir significativamente os requisitos de dados on-chain dividindo a execução no jogo de desafio-resposta em vez de realizá-lo inteiramente. Finalmente, implementar funções de hash como Keccak-256 e Grøstl no script do Bitcoin identificará a função de hash mais amigável ao Bitcoin e explorará outras novas funções de hash amigáveis ao Bitcoin.

3.4 Scripts sem Scripts BitVM

Scriptless Scripts é um método de execução de contratos inteligentes off-chain usando assinaturas Schnorr. O conceito de Scriptless Scripts originou-se de Mimblewimble, onde nenhum dado permanente é armazenado além do kernel e sua assinatura.

As vantagens dos Scripts sem Script incluem funcionalidade, privacidade e eficiência:

• Funcionalidade: Os Scripts sem script podem expandir o escopo e a complexidade dos contratos inteligentes. As capacidades do script do Bitcoin são limitadas pelo número de OP_CODES habilitados na rede. Em contraste, os Scripts sem script movem a especificação e a execução de contratos inteligentes para fora da cadeia para discussões apenas entre as partes do contrato, sem esperar que a rede Bitcoin bifurque para habilitar novos opcodes.
• Privacidade: Mover a especificação e execução de contratos inteligentes da cadeia para fora da cadeia melhora a privacidade. Na cadeia, muitos detalhes do contrato são compartilhados com toda a rede, incluindo o número de participantes, endereços e o valor transferido. Mover contratos inteligentes para fora da cadeia significa que a rede só sabe que os participantes concordaram que os termos do contrato foram cumpridos e que as transações relacionadas são válidas.
• Eficiência: Os Scriptless Scripts minimizam a quantidade de dados que precisa ser verificada e armazenada na cadeia. Ao mover contratos inteligentes para fora da cadeia, os custos administrativos para nós completos são reduzidos e as taxas de transação para os usuários também são reduzidas.

Os scripts sem script representam uma maneira de projetar protocolos criptográficos no Bitcoin que evita a execução de contratos inteligentes explícitos. A ideia principal é usar algoritmos criptográficos para alcançar a funcionalidade desejada em vez de usar scripts. As assinaturas de adaptadores e as multi-assinaturas são blocos de construção fundamentais dos scripts sem script. Com os scripts sem script, as transações podem ser menores do que as transações convencionais, reduzindo assim as taxas de transação.

Os Scripts sem script podem ser usados para implementar compromissos de portas lógicas no circuito BitVM, economizando espaço de script BitVM e aprimorando a eficiência do BitVM, usando assinaturas multi-sig Schnorr e assinaturas de adaptador em vez de fornecer valores de hash e pré-imagens como a solução BitVM. Embora os esquemas atuais de Scripts sem script possam reduzir o espaço de script BitVM, eles exigem uma extensa interação entre o provador e o desafiante para combinar chaves públicas. As melhorias futuras visarão integrar Scripts sem script em módulos funcionais BitVM específicos.

3.5 Desafios de Multi-partes sem Permissão

O desafio BitVM atual requer permissão porque uma UTXO de Bitcoin só pode ser executada uma vez, levando a uma situação onde um verificador mal-intencionado poderia "desperdiçar" o contrato desafiando um provador honesto. BitVM está atualmente restrito a um modelo de desafio de duas partes. Um provador mal-intencionado poderia usar um verificador sob seu controle para iniciar um desafio e "desperdiçar" o contrato, garantindo assim que sua ação maliciosa tenha sucesso, enquanto outros verificadores não podem impedir esse comportamento. Portanto, além do Bitcoin, é necessário pesquisar um protocolo de desafio OP de várias partes sem permissão que poderia expandir o modelo de confiança 1-de-n do BitVM existente para 1-de-N, onde N é muito maior que n. Além disso, é importante abordar questões de colusão entre desafiantes e provadores ou desafios maliciosos que "desperdiçam" contratos para alcançar um protocolo BitVM mais minimizado em confiança.

Um desafio de várias partes sem permissão permite que qualquer pessoa participe sem uma lista branca, o que significa que os usuários podem sacar do L2 sem o envolvimento de qualquer terceiro confiável. Além disso, qualquer usuário que queira se envolver no protocolo de desafio OP pode questionar e remover retiradas inválidas.

Expandir o BitVM para um modelo de desafio multi-party sem permissão envolve abordar os seguintes ataques:

• Ataques de Sybil: Mesmo que um atacante crie múltiplas identidades para participar do desafio de disputa, um único participante honesto ainda deve ser capaz de vencer a disputa. Se o custo para um participante honesto defender o resultado correto cresce de forma linear com o número de atacantes, o custo para o participante honesto vencer a disputa se torna impraticável e vulnerável a ataques de Sybil ao envolver um grande número de atacantes. O artigo Torneios Arbitrados Sem Permissão"Propõe um algoritmo de resolução de disputas que muda as regras do jogo, onde o custo para um único participante honesto vencer a disputa cresce de forma logarítmica, não linear, com o número de oponentes.
• Ataques de atraso: um indivíduo ou grupo de agentes mal-intencionados segue uma estratégia para impedir ou atrasar a confirmação do resultado correto (como retirar ativos para L1) em L1, forçando o provador honesto a gastar taxas de transação L1. Para mitigar esse problema, os desafiantes podem ser obrigados a fazer uma aposta inicial. Se um desafiante lançar um ataque de atraso, sua participação será perdida. No entanto, se os atacantes estiverem dispostos a sacrificar sua participação até certo ponto para perseguir ataques de atraso, deve haver estratégias para reduzir o impacto desses ataques. O algoritmo proposto no artigo "BoLD: Bounded Liquidity Delay in a Rollup Challenge ProtocolGarante que o atraso máximo causado pelo atacante seja limitado, independentemente de quanto o atacante esteja disposto a perder.

No futuro, haverá uma exploração de um modelo de desafio multipartidário sem permissão BitVM que é resistente a esses ataques e adequado para as características do Bitcoin.

4. Conclusão

A exploração da tecnologia BitVM está apenas começando e, no futuro, mais otimizações serão exploradas e praticadas para alcançar a escalabilidade do Bitcoin e enriquecer o ecossistema do Bitcoin.

Isenção de responsabilidade：

1. Este artigo é reproduzido a partir de [@Bitlayer/bitvm-and-its-optimization-considerations-007da599d8ac">Bitlayer], Todos os direitos autorais pertencem ao autor original [Lynndell e Mutourend]. Se houver objeções a este reenvio, entre em contato com o Gate Learnequipe e eles vão lidar com isso prontamente.
2. Isenção de Responsabilidade: As opiniões expressas neste artigo são exclusivamente do autor e não constituem conselhos de investimento.
3. As traduções do artigo para outros idiomas são feitas pela equipe Gate Learn. Salvo indicação em contrário, é proibido copiar, distribuir ou plagiar os artigos traduzidos.