Resumo

Este artigo explora os métodos práticos para permitir a verificação ZK no Bitcoin, abordando tópicos como o modelo UTXO do Bitcoin, limitações de script, Taproot, OP_CAT, BitVM e Provas de Estado de Cadeia. Ele apresenta um argumento claro de que a integração da ZK no protocolo Bitcoin é inevitável. Duas rotas potenciais são destacadas: uma é a reintrodução do opcode OP_CAT para suportar diretamente a verificação SNARK em scripts Bitcoin - uma mudança que tem uma alta probabilidade de aprovação eventual. A segunda abordagem gira em torno do BitVM, que incorpora provas de fraude. Além disso, a proposta da equipe ZeroSync para Provas de Estado de Cadeia tem como objetivo reduzir o custo de verificação de dados históricos para clientes de nós.

Texto Principal: Para entender completamente o Bitcoin, é útil vê-lo como um sistema social. Nos primeiros dias, os criadores do Bitcoin definiram o software que os nós devem executar, assim como estabelecer as regras que governam uma sociedade. A estabilidade do Bitcoin depende de um amplo consenso sobre sua natureza fundamental, levando a perguntas como 'O que é o Bitcoin em sua essência?' e 'Como o Bitcoin deve evoluir?'. No entanto, chegar a um consenso sobre essas questões é notoriamente difícil, pois as opiniões variam amplamente e continuamente se desenvolvem.

Isso remonta à origem histórica do Bitcoin. Quando Satoshi Nakamoto lançou o white paper do Bitcoin, ele disse: “Estou trabalhando em um novo sistema de pagamento eletrônico. Este sistema é completamente P2P e não precisa depender de terceiros.” Este trecho foi publicado na lista de discussão Cypherpunks (um grupo de discussão por e-mail estabelecido em 1992, composto por um grupo de criptógrafos e entusiastas da tecnologia que estão preocupados com a proteção da privacidade e a tecnologia de criptografia).

No entanto, o Bitcoin limita a taxa de transferência de dados ao nível do design do produto. O número de transações que pode processar por unidade de tempo é limitado. Se o número de transações a serem processadas aumentar rapidamente, os usuários iniciarão uma guerra de preços para concluir com sucesso a transação rapidamente, aumentando rapidamente as taxas de processamento pagas. A única transação com a maior taxa de processamento na rede Bitcoin ocorreu após a redução pela metade da recompensa do bloco em 2024, e a taxa de processamento para uma transação com prioridade média na cadeia atingiu $150. Pode-se dizer que as caras taxas de transação da rede Bitcoin se tornaram um problema.

Para resolver o problema das taxas de transação, as pessoas investiram muitos recursos no desenvolvimento da Lightning Network. Mas, de acordo com um artigo publicado em 2016, a Lightning Network só pode suportar dezenas de milhões de usuários na prática e não pode realizar sua visão de um sistema de pagamento global. Além das taxas de transação excessivamente caras, há outro problema, isto é o Bitcoin nunca foi capaz de alcançar o anonimato que imaginava.

Satoshi Nakamoto apontou em um grupo de discussão por e-mail do cypherpunk que o Bitcoin tem uma função de proteção da privacidade e o iniciador da transação pode ser completamente anônimo. No entanto, embora o iniciador da transação não exija KYC, os dados da transação na cadeia do Bitcoin vazam muitas informações, expondo a privacidade do usuário em grande medida. Embora existam alguns clientes de carteira com funções de privacidade que resolvem os problemas acima em certa medida, os desenvolvedores desses clientes de carteira enfrentam ameaças de vários tamanhos. Por exemplo, o desenvolvedor da carteira Samourai CoinJoin foi preso pelo FBI em abril de 2024 e, uma semana depois, o desenvolvedor da carteira Wasabi desligou seu componente de coordenação CoinJoin. Obviamente, essas chamadas carteiras de privacidade não são totalmente dignas de confiança dos usuários.

Em resumo, muitos dos conceitos do Bitcoin estão longe de serem realizados até hoje, e as tecnologias relacionadas ainda estão em contínuo desenvolvimento. Mesmo assim, muitas pessoas na comunidade do Bitcoin acreditam que o design do protocolo do Bitcoin deve permanecer inalterado, mas também há muitas pessoas, como eu, que são apaixonadas por fazer melhorias no Bitcoin. Então, em que direção o Bitcoin deve melhorar?

Em resposta às questões acima, há muitas propostas na comunidade Bitcoin, e aquelas com os melhores resultados teóricos devem estar relacionadas ao ZK e SNARKs. Com ZK e SNARKs, podem ser alcançadas as seguintes características:

1. Privacidade significativamente melhorada: utilize o compromisso homomórfico de Peterson para o valor da transação e a Prova de Intervalo para melhorar significativamente a privacidade do usuário (como feito na cadeia lateral Element da Blockstream); utilize assinaturas vinculáveis (como Monero) para ocultar rastros de transações; realize transações verdadeiramente privadas (como Zcash).

2. Aumentar a capacidade de transação

Muitas soluções técnicas poderiam abordar os problemas existentes do Bitcoin, mas por que essas tecnologias ainda não foram integradas ao protocolo do Bitcoin? A resposta está na dificuldade de modificar o protocolo. Ao contrário do Ethereum, o Bitcoin não tem uma organização centralizada como a Ethereum Foundation. Qualquer mudança de protocolo requer um alto nível de consenso da comunidade, envolvendo extensas negociações e equilíbrio de interesses. Como resultado, enquanto o Ethereum atualiza regularmente seus códigos de operação EVM, o protocolo do Bitcoin viu muito poucas mudanças desde sua criação.

De certa forma, essa dificuldade em modificar o protocolo é benéfica. Se as mudanças fossem fáceis de implementar, as alterações ou ataques maliciosos seriam mais prováveis. Isso levanta a questão: Como pode ser melhorado o desempenho do Bitcoin sem alterar o protocolo?

Para responder a isso, precisamos revisitar alguns conceitos básicos do Bitcoin. Quando você transfere Bitcoin para outra pessoa, cria uma transação e a transmite para a rede Bitcoin. Os dados de saída da transação especificam a quantidade de BTC sendo transferida. O destinatário pode então criar uma nova transação para gastar os BTC recebidos, gerando novos dados de saída no processo.

É importante observar que o Bitcoin não possui um estado global como o Ethereum, especialmente a falta de um estado de conta; ele possui apenas dados de saída de transações. Cada saída de transação possui dois estados: ou foi gasta pelo destinatário ou permanece não gasta. As saídas de transação não gastas (UTXOs) são o que estamos familiarizados. Além do valor em BTC associado, cada saída de transação também possui um script anexado escrito em Bitcoin Script. Quem puder fornecer a prova correta (Testemunha) para esse script pode gastar a UTXO.

O Bitcoin Script é uma linguagem de programação baseada em pilha com uma série de opcodes. Os programas anexados aos UTXOs geralmente consistem em vários opcodes, realizando cálculos baseados na pilha e retornando resultados para ela. Muitos scripts comuns do Bitcoin existem desde a criação do Bitcoin. Por exemplo, o script mais comum consiste em uma chave pública e um opcode que verifica a assinatura digital. Este opcode exige que, para gastar ou desbloquear um UTXO, seja fornecida uma assinatura digital correspondente à chave pública.

Leitura recomendada: [Aproximando-se do BTC: Conhecimento de Fundo para Compreender BitVM (1)]

Capacidades do Bitcoin Script

O que o Script do Bitcoin pode fazer:

• Rearranjar a pilha e realizar verificações de igualdade (para verificar condições específicas e garantir a segurança e validade da transação).
• Realize operações condicionais semelhantes às declarações if-else.
• Realize operações aritméticas limitadas em números de 32 bits, como adição e subtração.
• Verificar dados de hash e assinaturas ECDSA e Schnorr.

O que o Bitcoin Script Não Pode Fazer:

• Sem loops, saltos ou recursão; não é Turing-completo, com capacidades de programação muito limitadas.
• Não é possível realizar operações bit a bit.
• Falta opcodes para multiplicação e divisão.
• Não é possível concatenar elementos na pilha.
• Tem capacidade muito limitada para ler e verificar dados de transações na cadeia. O Bitcoin Script não pode acessar diretamente a quantidade de cada transação e não pode passar estado (os UTXOs são de uso único, e cada transferência queima os antigos e gera novos).

Nas primeiras versões do Bitcoin, algumas das funcionalidades de 'não-pode-fazer' mencionadas acima eram possíveis, mas certos opcodes foram posteriormente desabilitados por Satoshi Nakamoto devido a vulnerabilidades de segurança. Por exemplo, o opcode OP_CAT, que poderia combinar dois elementos de pilha, foi usado para atacar remotamente os nós do Bitcoin e causar falhas. Satoshi desabilitou OP_CAT e outros opcodes por motivos de segurança.

Portanto, o Bitcoin Script pode verificar SNARKs? Teoricamente, mesmo que o Bitcoin Script não seja Turing-completo, suas operações básicas são suficientes para verificar qualquer computação. No entanto, na prática, a verificação de SNARK não é viável porque o tamanho do programa necessário para as etapas de verificação excede o limite máximo de bloco do Bitcoin de 4MB. Embora pudéssemos tentar operações aritméticas em campos finitos grandes, o custo seria proibitivamente alto. Por exemplo, no BitVM, multiplicar dois inteiros de 254 bits resultou em um tamanho de script do Bitcoin de quase 8KB. Além disso, sem OP_CAT, o custo de verificar provas de Merkle também é alto, pois isso requer operações semelhantes a loops.

Então, por que não apenas modificar o protocolo do Bitcoin para adicionar opcodes mais poderosos? Como mencionado anteriormente, alcançar um consenso majoritário sobre novas regras de protocolo é extremamente difícil. O Bitcoin não possui um tomador de decisões centralizado, e qualquer proposta para melhorar o Bitcoin Script enfrenta considerável oposição de partes interessadas com perspectivas diferentes. Não existe uma maneira eficaz de medir o consenso da comunidade na rede Bitcoin, e forçar uma atualização sem isso pode levar a divisões na cadeia. Claro, o Bitcoin não é totalmente imutável. As atualizações mais recentes foram o SegWit em 2017 e o Taproot em 2021.

A atualização Taproot, que alterou muitas regras, levou três anos e meio para passar do lançamento teórico para a ativação real. O fator-chave para permitir o Taproot foi que ele não alterou suposições de segurança existentes e fez melhorias claras no protocolo Bitcoin. Por exemplo, ele permite o uso de assinaturas Schnorr em vez de ECDSA. Ambos são baseados na suposição do logaritmo discreto e usam a mesma curva elíptica, mas o primeiro é mais eficiente e requer menos computação.

Além disso, as melhorias do Taproot no Bitcoin podem ser categorizadas nos seguintes três aspectos:

Primeiro, o Taproot reduz os custos de verificação de scripts com muitos ramos condicionais, permitindo que o Bitcoin suporte programas mais complexos.

Em segundo lugar, Taproot reduz a quantidade de dados de script a ser revelada na cadeia, e você pode montar vários programas de script em uma árvore de Merkle, com cada script localizado em uma folha diferente. Se você deseja acionar um determinado script, você só precisa revelar a folha onde ele está localizado e a prova de Merkle;

Terceiro, Taproot também adicionou outros designs de mecanismos.

Considerando o precedente do Bitcoin com o Taproot para integrar recursos mais avançados, pode-se perguntar por que um opcode dedicado para verificação SNARK não foi introduzido. A principal diferença está na complexidade e no consenso necessários para OP_SNARK. Ao contrário do Taproot, que tinha um design claro e direto que ganhou amplo apoio, OP_SNARK propostas variam muito, tornando difícil reunir a comunidade em torno de uma única abordagem. Se implementado, cada nó Bitcoin precisaria suportar esse método específico de verificação SNARK, o que aumentaria significativamente as demandas técnicas. Além disso, a complexidade inerente de OP_SNARK é um grande obstáculo – o Taproot adicionou cerca de 1.600 linhas de código, gerenciáveis pelos padrões da comunidade, enquanto OP_SNARK implicaria uma codificação muito mais complexa. Além disso, determinar quem avaliaria a ativação de OP_SNARK e alcançar consenso quando poucos compreendem completamente seus meandros adiciona camadas de dificuldade. Diante desses desafios, é improvável que uma atualização OP_SNARK se materialize em um futuro próximo.

No entanto, existem outras maneiras de verificar SNARKs no Bitcoin Script. Podemos tornar os scripts do Bitcoin mais funcionais adicionando opcodes mais simples, permitindo que as pessoas implementem programas validadores SNARK em scripts. Mas, na verdade, é muito difícil escrever um programa de verificação SNARK na linguagem de script do Bitcoin. Portanto, a equipe de pesquisa da Blockstream está desenvolvendo o Simplicity, uma linguagem de programação projetada para substituir o Bitcoin Script. O Simplicity é especificamente projetado para sistemas de consenso de blockchain e intencionalmente não é Turing-completo, facilitando a análise estática e a verificação formal.

Vamos voltar nossa atenção para uma proposta aparentemente simples, mas altamente impactante que poderia melhorar significativamente as capacidades de script do Bitcoin: a reativação do opcode OP_CAT. OP_CAT foi originalmente incluído no código inicial do Bitcoin, mas foi posteriormente desativado por Satoshi Nakamoto devido ao seu potencial para permitir ataques DoS em condições específicas. No entanto, agora há um interesse crescente dentro da comunidade do Bitcoin em trazê-lo de volta.

A função do OP_CAT é direta - ele pega os dois elementos do topo da pilha, os concatena e depois empurra o resultado de volta para a pilha. Embora isso possa parecer básico, ele tem o potencial de desbloquear melhorias substanciais na linguagem de script do Bitcoin. Por exemplo, scripts atuais do Bitcoin não podem acessar certos dados de transação on-chain, como os valores envolvidos, mas com o OP_CAT, essa capacidade poderia ser introduzida. Além disso, o OP_CAT poderia ser fundamental na verificação de provas de Merkle.

Essencialmente, OP_CAT é uma atualização de opcode de baixo nível que pode levar a uma ampla gama de novas funcionalidades. Muitos apontaram que OP_CAT poderia ser crucial para alcançar diversos objetivos. Uma questão chave é se OP_CAT poderia ajudar na verificação de SNARKs dentro de scripts. A resposta é sim. Como a verificação de prova de Merkle é um passo para validar SNARKs baseados em FRI, OP_CAT seria uma adição valiosa. No passado, scripts projetados para verificação de SNARKs podem ter sido muito grandes para caber nos limites de tamanho de bloco do Bitcoin, mas OP_CAT poderia ajudar a simplificar esses scripts, tornando-os mais compactos.

O OP_CAT tem sido discutido há anos, com uma crescente conscientização sobre seu papel potencial na introspecção de transações. Uma de suas principais vantagens em relação a outras propostas é que ele já foi uma parte integrante do Bitcoin Script, o que poderia facilitar a obtenção de consenso da comunidade. No entanto, a desvantagem é que a ativação do OP_CAT poderia impactar negativamente os lucros do MEV (Valor Minerável pelo Minerador) para alguns, o que levou a um debate contínuo dentro da comunidade sobre sua reativação.

Em resumo, o Bitcoin poderia dar um passo em direção à habilitação da verificação SNARK em scripts reintroduzindo opcodes simples como OP_CAT. Além disso, vale mencionar uma proposta recente chamada "Grande Restauração de Script", que reintroduz um opcode de multiplicação e permite que todas as operações aritméticas sejam realizadas com precisão arbitrária.

Além disso, ao avaliar o impacto do OP_CAT na rede Bitcoin, é importante considerar seus efeitos sobre os operadores de nós Bitcoin. Para garantir que o Bitcoin permaneça resistente à censura e descentralizado, a comunidade se esforça para ter o maior número possível de pessoas executando nós para validar transações. Se o Bitcoin implementasse a verificação SNARK, não aumentaria significativamente o custo de operação de um nó, o que não afetaria muito a segurança ou resistência à censura do Bitcoin.

Atualmente, um bloco Bitcoin pode conter até 4MB de dados, com novos blocos sendo minerados aproximadamente a cada 10 minutos. A maioria dos blocos é preenchida com scripts Bitcoin e dados de Testemunha (semelhantes a assinaturas digitais). Em média, cada bloco pode acomodar entre 7.000 e 10.000 verificações de assinatura, com um máximo de cerca de 80.000 verificações por bloco. Para contextualizar, meu CPU Intel de 2020 leva cerca de 3,2 segundos para verificar um bloco Bitcoin. Naturalmente, a velocidade de verificação do bloco é influenciada por fatores além do tempo de verificação da assinatura.

Além disso, se as transações de Bitcoin eventualmente suportarem provas de conhecimento zero (ZK), qualquer aumento no tempo de geração de transações pode não ser uma preocupação importante. Carteiras de hardware, que são usadas para armazenamento de ativos a longo prazo, geralmente têm telas e designs compactos focados no armazenamento de chaves e na criação de assinaturas. Essas carteiras geralmente apresentam CPUs de baixa potência, como um processador dual-core de 240MHz, mas lidam eficientemente com transações de Bitcoin.

Eu fiz uma pequena pesquisa perguntando aos usuários sobre o atraso máximo que aceitariam para um dispositivo de assinatura gerar uma prova, e muitas pessoas ficaram bem com uma espera mais longa, especialmente se houvesse ganhos significativos a serem feitos. Então, se introduzirmos ZK em transações Bitcoin, não parece haver muitos problemas. Passamos muito tempo discutindo possíveis mudanças no design subjacente do Bitcoin, mas existem muitas aplicações que podem ser desenvolvidas sem alterar o Bitcoin em si. Uma dessas aplicações dignas de menção é a Prova de Estado de Cadeia, que está relacionada ao BitVM. Essa abordagem usa provas de conhecimento zero para validar a correção dos hashes de bloco.

Qual é o impacto dessa tecnologia no Bitcoin? Em primeiro lugar, as Provas de Estado da Cadeia podem reduzir significativamente o trabalho envolvido na sincronização e verificação dos dados históricos do Bitcoin, o que por sua vez reduz os custos de execução de um nó. Atualmente, a sincronização e verificação de dados desde o bloco de gênese até o bloco mais recente leva cerca de 5 horas e 30 minutos em um dispositivo de alta qualidade e vários dias em um dispositivo de nível Raspberry Pi. As Provas de Estado da Cadeia poderiam encurtar significativamente esse processo.

Em segundo lugar, as Provas de Estado da Cadeia desempenham um papel crucial no avanço do BitVM. A equipe ZeroSync pesquisou minuciosamente as Provas de Estado da Cadeia e desenvolveu uma versão simplificada chamada "Provas da Cadeia de Cabeçalho". Esta abordagem utiliza provas de conhecimento zero para validar os cabeçalhos dos blocos do Bitcoin, criando uma "cadeia de cabeçalho" que abrange todos os 850.000 cabeçalhos de bloco na história do Bitcoin. Cada cabeçalho de bloco é hashado para produzir uma prova de 80 bytes. Este método requer cálculos duplos de SHA-256 para cada cabeçalho para verificar a prova de trabalho associada. O ZeroSync utiliza STARKs para gerar essas provas da cadeia de cabeçalho, custando cerca de $4.000 para produzir, enquanto a verificação leva apenas cerca de 3 segundos no meu navegador.

No entanto, uma vez que as provas da cadeia de cabeçalho não verificam as transações dentro dos blocos, elas só podem presumir que a blockchain com a maioria do trabalho de prova (PoW) é válida e confiar nos clientes do Bitcoin para sincronizar os últimos blocos dessa cadeia. Nessa configuração, um atacante teoricamente poderia criar blocos com transações inválidas, adicionar mais blocos após eles e gerar uma prova de cadeia de cabeçalho para enganar os clientes que sincronizam dados históricos. No entanto, o custo de tal ataque seria proibitivamente alto e provavelmente seria detectado pelos clientes de nó completo do Bitcoin existentes.

No entanto, mesmo que as chances de tal ataque ter sucesso sejam baixas, se isso permitir que os atacantes roubem uma quantidade significativa de BTC, as provas da cadeia de cabeçalho não seriam consideradas uma solução completamente segura. Para verificar o estado completo da cadeia, precisamos garantir que todos os conteúdos dos blocos do Bitcoin sejam válidos, incluindo verificações de assinaturas ECDSA e Schnorr baseadas na curva elíptica secp256k1. Os blocos históricos do Bitcoin contêm aproximadamente 30 milhões de assinaturas por mês, totalizando cerca de 2,5 bilhões de assinaturas historicamente, juntamente com inúmeras computações SHA-256. Como resultado, a rede do Bitcoin gera cerca de 7GB de dados de bloco mensalmente, com dados históricos superando 650GB - e na prática, esse número pode ser de 2 a 3 vezes maior.

Agora, vamos dar uma olhada no BitVM. O BitVM permite que o Bitcoin verifique qualquer tarefa computacional, fornecendo uma maneira ideal de realizar a verificação SNARK sem modificar o protocolo. O BitVM supera as limitações de tamanho de script do Bitcoin usando dois métodos. Primeiro, ele aproveita a estrutura do script Taproot MerkleTree. Em segundo lugar, ele usa um esquema de armazenamento KV que pode ser acessado por meio de scripts individuais, facilitando conexões com um grande número de programas de script. No entanto, o protocolo Bitcoin não impõe a integridade desse esquema de armazenamento KV. O BitVM aborda isso empregando provas de fraude para detectar Provers maliciosos. Se um Prover fizer alegações inválidas ou usar um armazenamento KV com falhas, outros podem iniciar uma transação na blockchain do Bitcoin para relatar a má conduta do Prover e apreender os ativos apostados do Prover.

Em resumo, o Bitcoin está lidando com desafios significativos e, embora várias propostas tenham sido apresentadas para abordá-los, é improvável que ganhem aceitação rápida da comunidade do Bitcoin. Mudanças no protocolo não são viáveis a curto prazo, refletindo tanto as forças quanto as limitações da descentralização e segurança do Bitcoin. O potencial dos SNARKs e STARKs está gerando considerável entusiasmo dentro da comunidade. O BitVM parece ser o método mais promissor para integrar a verificação de SNARK a médio e longo prazo, embora exija mais pesquisa e desenvolvimento para ser totalmente prático. Reabilitar o opcode OP_CAT é outra abordagem a ser explorada, mas é necessário demonstrar que os benefícios da reativação superam os riscos e identificar quais opcodes simples poderiam facilitar a verificação de SNARK ou funções similares nos scripts do Bitcoin. Em última análise, a comunidade do Bitcoin tem como objetivo aprimorar a praticidade da tecnologia e apoiar casos de uso mais acionáveis.

Leia o conteúdo original aqui: https://www.youtube.com/watch?v=GrSCZmFuy7U

Aviso Legal:

1. Este artigo é reproduzido de [Geek Web3], Todos os direitos autorais pertencem ao autor original [ Geek Web3]. Se houver objeções a esta reimpressão, entre em contato com oGate 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 nenhum 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, copiar, distribuir ou plagiar os artigos traduzidos é proibido.