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, embora o Bitcoin possa realizar scripts simples e transações multi-assinatura, tem dificuldade em facilitar as interações de contratos complexos e dinâmicos comuns em plataformas de blockchain com estado. Essa limitação restringe significativamente a gama de aplicações descentralizadas (dApps) e instrumentos financeiros complexos que podem ser construídos no Bitcoin, enquanto os modelos de plataformas 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 fornecem uma solução de pagamento segura e diversificada, mas têm capacidade limitada para verificar computações arbitrariamente complexas. Essa limitação reduz sua aplicabilidade em vários cenários que exigem lógica e interações complexas e condicionais. As sidechains suportam uma ampla gama de aplicações e oferecem diversidade além das capacidades do Bitcoin, mas têm menor segurança. Essa diferença de segurança decorre do uso por sidechains de mecanismos de consenso independentes, 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, o que leva a uma segurança menor. 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: Calcular Qualquer Coisa no Bitcoin”, o que desencadeou considerável reflexão sobre a melhoria da programabilidade do Bitcoin. O artigo propõe uma solução de contrato Bitcoin completa de Turing que pode executar qualquer cálculo complexo no Bitcoin sem alterar as regras de consenso da rede ou modificar os princípios fundamentais do Bitcoin. BitVM aproveita scripts Bitcoin e Taproot para implementar Rollups otimistas. Utiliza assinaturas Lamport (também conhecidas como compromisso de bit) para estabelecer conexões entre dois UTXOs do Bitcoin, permitindo scripts Bitcoin com estado. Um programa extenso é comprometido dentro de um endereço Taproot, e operadores e validadores envolvem-se em extensas interações fora da cadeia, deixando uma pegada mínima na blockchain. Se ambas as partes cooperarem, qualquer cálculo complexo e com estado fora da cadeia pode ser executado sem deixar rasto na 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 potenciais do Bitcoin, permitindo-lhe servir não apenas como moeda, mas também como 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, ela ainda está nos estágios iniciais e enfrenta alguns problemas de eficiência e segurança, tais como: (1) Desafios e respostas que exigem múltiplas interações, resultando em taxas de transação elevadas e períodos de desafio longos; (2) As assinaturas únicas de Lamport têm comprimentos de dados longos, exigindo uma redução no tamanho dos dados; (3) A complexidade da função hash elevada requer funções hash amigáveis ao Bitcoin para reduzir custos; (4) Os contratos BitVM existentes são grandes, e a capacidade do bloco do Bitcoin é limitada, portanto, o uso de scripts sem script poderia ajudar a alcançar o BitVM de Scripts sem Script, economizando espaço de bloco do Bitcoin e aprimorando a eficiência do BitVM; (5) O BitVM atual opera em um modelo de permissão, com desafios iniciados apenas por 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 abordar essas questões, o artigo sugere várias ideias de otimização para melhorar a eficiência e segurança do BitVM.

2. BitVM Princípio

BitVM é posicionado como um sistema de contrato fora da cadeia para Bitcoin, com o objetivo de avançar a funcionalidade de contrato do Bitcoin. Atualmente, os scripts do Bitcoin são inteiramente sem estado, o que significa que o ambiente de execução é redefinido após cada script. Não há uma maneira nativa nos scripts 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 com estado usando opcodes existentes e assinaturas de Lamport de uso único, garantindo que x no script1 e script2 sejam iguais. Se os participantes assinarem valores conflitantes de x, eles podem ser penalizados.

As computações BitVM ocorrem fora da cadeia, enquanto a verificação dessas computações ocorre na cadeia. Dado o limite de 1MB dos blocos Bitcoin, quando a verificação de computações complexas é necessária, a tecnologia OP pode ser usada em modo de desafio-resposta para suportar a 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. As primitivas subjacentes do BitVM são simples, baseadas principalmente em bloqueios de hash, bloqueios de tempo e grandes árvores Taproot.

Os provadores comprometem-se com o programa byte a byte, mas verificar todas as computações na cadeia seria proibitivamente caro. Portanto, os verificadores realizam uma série de desafios cuidadosamente projetados para refutar sucintamente as falsas alegações do provador. Os 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 num circuito binário grande. O provador compromete-se com este circuito num endereço Taproot, sendo que cada script de folha sob esse endereço corresponde a cada porta lógica no circuito. O cerne é alcançar um compromisso de porta lógica com base no compromisso de bit.
• Desafio e resposta: Os provadores e verificadores pré-assinam uma série de transações para implementar o jogo de desafio-resposta. Idealmente, esta interação ocorre fora da cadeia, mas também pode ser executada na cadeia se o provador for incooperativo.
• Penalização ambígua: Se o provador fizer reivindicações incorretas, o verificador pode pegar 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 baseiam-se na verificação de validade das Provas de Conhecimento Zero (ZK), que são provas criptográficas de execução correta. A sua segurança depende de suposições de complexidade computacional. Optimistic Rollups baseiam-se em Provas de Fraude, assumindo que todos os estados submetidos estão corretos e geralmente estabelecendo um período de desafio de cerca de sete dias. A sua segurança pressupõe que pelo menos uma parte honesta no sistema pode detetar o estado incorreto e submeter uma prova de fraude.

Supondo que a contagem máxima de passos para o programa de desafio do BitVM seja 2^{32}, seria necessário 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 do script de cerca de 150KB. Tal 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 melhorar a sua eficiência. De acordo com 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á o Verify, produzindo Falso. No sistema BitVM, se o desafiante não aceitar os dados do provador, um desafio é iniciado.

Para o algoritmo F, utilizando 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 demorar 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 reside 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 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 Zero-Conhecimento e Provas de Fraude dependa de pressupostos de segurança diferentes, 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 é feito um desafio, mantendo um design otimista onde o estado gerado é considerado válido até ser desafiado. Se um estado não for desafiado, nenhuma Prova de ZK é necessária. No entanto, se houver um desafio, 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, as transações que seguem as regras de consenso são consideradas válidas, mas para além destas regras, existe um conceito adicional de padronização. Os nós de Bitcoin apenas propagam e difundem transações padrão, e a única maneira de transações válidas mas não padrão serem incluídas num bloco é através da colaboração direta com os mineiros.

De acordo com as regras de consenso, o tamanho máximo para transações legacy (não-Segwit) é de 1MB, o que poderia preencher um bloco inteiro. No entanto, o limite de padronização para transações legacy é definido em 100kB. Para transações Segwit, o tamanho máximo permitido pelas regras de consenso é de 4MB, conhecido como o limite de peso, mas o limite de padronização é 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 exigem 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 os comprimentos da chave pública e da assinatura são ambos 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 bastante os comprimentos das assinaturas e chaves públicas, mas aumentam a complexidade computacional da 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 menores do que os do esquema de assinatura única de Lamport, mas a complexidade da verificação é quatro vezes maior. Usar d=15, v=160, f=ripemd160(x) em 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 da transação Segwit, que é de 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 de caminho de Merkle. Portanto, há necessidade de implementar uma função de 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 para o tamanho da testemunha do script, para suportar a verificação da prova de inclusão de Merkle.

O BLAKE3 é uma versão otimizada da função hash BLAKE2 e introduz um modo de árvore Bao. Comparado ao baseado em BLAKE2s, a contagem de rodadas da função de compressão foi reduzida de 10 para 7. A função hash BLAKE3 divide a 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 o único nó da árvore. Esses pedaços são organizados como nós folha de uma árvore binária, e cada pedaço é comprimido independentemente.

Quando 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 dentro de um único bloco, significando 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, são necessárias sete funções de rodada e seis funções de permutação.

O BitVM já implementou operações básicas como XOR, adição modular e deslocamento de bits à direita com base em valores u32, tornando simples a montagem de 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 pelo BLAKE3. A função de hash BLAKE3 no script do Bitcoin tem atualmente cerca de 100kB, o que é 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 ao dividir a execução no jogo de desafio-resposta em vez de realizá-lo completamente. Finalmente, a implementação de 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

Scripts sem scripts são um método de execução de contratos inteligentes fora da cadeia usando assinaturas Schnorr. O conceito de Scripts sem scripts teve origem em Mimblewimble, onde não é armazenados dados permanentes além do núcleo e sua assinatura.

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

• Funcionalidade: Os Scripts sem Script podem expandir o alcance e a complexidade dos contratos inteligentes. As capacidades do script do Bitcoin são limitadas pelo número de OP_CODES ativados na rede. Em contraste, os Scripts sem Script movem a especificação e execução dos contratos inteligentes fora da cadeia para discussões apenas entre as partes do contrato, sem esperar que a rede Bitcoin bifurque para habilitar novos opcodes.
• Privacidade: Ao mover a especificação e execução de contratos inteligentes da cadeia para fora da cadeia, aumenta-se a privacidade. Na cadeia, muitos detalhes do contrato são partilhados com toda a rede, incluindo o número de participantes, endereços e a quantia transferida. Ao mover os contratos inteligentes para fora da cadeia, significa que a rede apenas sabe que os participantes concordaram que os termos do contrato estão satisfeitos e que as transações relacionadas são válidas.
• Eficiência: Os Scripts sem Scripts minimizam a quantidade de dados que precisam ser verificados e armazenados na cadeia. Ao mover contratos inteligentes fora da cadeia, os custos administrativos para os nós completos são reduzidos, e as taxas de transação para os usuários também são diminuídas.

Os scripts sem script representam uma forma 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 adaptador e as multisig são blocos de construção fundamentais dos scripts sem script. Com scripts sem script, as transações podem ser mais pequenas 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, poupando espaço de script BitVM e melhorando a eficiência do BitVM, usando assinaturas multiplas Schnorr e assinaturas de Adaptador em vez de fornecer valores de hash e pré-imagens como a solução BitVM. Embora os esquemas de Scripts sem script atuais possam reduzir o espaço de script BitVM, eles exigem interação extensiva entre o provador e o desafiante para combinar chaves públicas. As futuras melhorias visarão integrar os Scripts sem script em módulos funcionais BitVM específicos.

3.5 Desafios Multi-party sem permissão

O desafio atual do BitVM requer permissão porque um UTXO Bitcoin só pode ser executado uma vez, levando a uma situação em que um verificador malicioso poderia "desperdiçar" o contrato desafiando um probador honesto. BitVM está atualmente restrito a um modelo de desafio de duas partes. Um probador malicioso 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 existente de 1-de-n do BitVM para 1-de-N, onde N é muito maior que n. Além disso, é importante abordar questões de conluio entre desafiantes e provadores ou desafios maliciosos que "desperdiçam" contratos para alcançar um protocolo BitVM mais minimizado em termos de confiança.

Um desafio multi-party sem permissão permite que qualquer pessoa participe sem uma lista branca, o que significa que os utilizadores podem retirar-se do L2 sem o envolvimento de qualquer terceira parte confiável. Além disso, qualquer utilizador que queira participar no protocolo de desafio OP pode questionar e remover levantamentos inválidos.

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

• Ataques de Sybil: Mesmo que um atacante crie várias identidades para participar no desafio de disputa, um único participante honesto ainda deve ser capaz de ganhar a disputa. Se o custo para um participante honesto defender o resultado correto cresce linearmente com o número de atacantes, o custo para o participante honesto ganhar a disputa torna-se impraticável e vulnerável a ataques de Sybil ao envolver um grande número de atacantes. O artigo Torneios Refereed Sem Permissão” propõe um algoritmo de resolução de disputas que altera 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 atores maliciosos segue uma estratégia para impedir ou atrasar a confirmação do resultado correto (como a retirada de ativos para L1) na L1, forçando o provador honesto a gastar taxas de transação L1. Para mitigar esse problema, poderia ser exigido que os desafiantes fizessem uma aposta inicial. Se um desafiante lançar um ataque de atraso, sua aposta seria perdida. No entanto, se os atacantes estiverem dispostos a sacrificar sua aposta até certo ponto para realizar ataques de atraso, deveriam existir 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 ele esteja disposto a perder.

No futuro, haverá uma exploração de um modelo de desafio multi-party sem permissão BitVM que é resistente a esses ataques e adequado às características do Bitcoin.

4. Conclusão

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

Aviso legal：

1. Este artigo é reproduzido a partir de [BIT@Bitlayer/bitvm-and-its-optimization-considerations-007da599d8ac">Bitlayer], Todos os direitos autorais pertencem ao autor original [Lynndell e Mutourend]. Se houver objeções a esta reimpressão, entre em contato com o Gate Aprenderequipa e eles vão tratar disso prontamente.
2. Aviso de responsabilidade: As opiniões expressas neste artigo são exclusivamente do autor e não constituem qualquer conselho 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.