Abstrato

Este artigo aborda os métodos práticos para permitir a verificação ZK no Bitcoin, abrangendo tópicos como o modelo UTXO do Bitcoin, limitações de script, Taproot, OP_CAT, BitVM e Chain State Proofs. Apresenta um argumento claro de que a integração do ZK no protocolo Bitcoin é inevitável. Duas rotas potenciais são destacadas: uma é reintroduzir o opcode OP_CAT para dar suporte direto à 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 Chain State Proofs visa reduzir o custo de verificação de dados históricos para clientes de nó.

Texto principal: Para compreender 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, tal como estabelecer as regras que regem uma sociedade. A estabilidade do Bitcoin depende de um amplo consenso sobre a sua natureza fundamental, levando a questões como "O que é o Bitcoin no seu âmago?" e "Em que deve o Bitcoin evoluir?" No entanto, alcançar consenso sobre estas questões é notoriamente difícil, uma vez que as opiniões variam amplamente e continuam a evoluir.

Isto remonta à origem histórica do Bitcoin. Quando Satoshi Nakamoto lançou o white paper do Bitcoin, ele disse: 'Estou a trabalhar num novo sistema de pagamento eletrónico. Este sistema é totalmente P2P e não precisa de depender de terceiros.' Este trecho foi publicado na lista de discussão Cypherpunks (um grupo de discussão por email estabelecido em 1992, composto por um grupo de criptógrafos e entusiastas de tecnologia preocupados com a proteção da privacidade e 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 utilizadores iniciarão uma guerra de preços para completar com sucesso a transação rapidamente, aumentando rapidamente as taxas de processamento pagas. A única transação com a taxa de processamento mais alta na rede Bitcoin ocorreu após a redução para 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 taxas de transação caras 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, ou seja, o Bitcoin nunca conseguiu alcançar o anonimato que ele idealizou.

Satoshi Nakamoto apontou em um grupo de discussão de e-mail cypherpunk que o Bitcoin tem uma função de proteção de 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 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 até certo ponto, 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 encerrou seu componente de coordenação CoinJoin. Obviamente, essas chamadas carteiras de privacidade não são totalmente dignas da confiança dos usuários.

Para resumir, 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 mencionadas, há muitas propostas na comunidade Bitcoin, e as que apresentam os melhores resultados teóricos devem estar relacionadas com ZK e SNARKs. Com ZK e SNARKs, podem ser alcançadas as seguintes funcionalidades:

1. Privacidade significativamente melhorada: utilize o compromisso homomórfico de Peterson para o montante 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 linkables (como o Monero) para ocultar rastros de transações; alcançar transações verdadeiramente privadas (como o Zcash).

2. Melhorar a capacidade de processamento de transações

Muitas soluções técnicas poderiam resolver 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 possui 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 suas opcodes EVM, o protocolo do Bitcoin teve pouquíssimas alterações desde o seu início.

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

Para responder a isso, precisamos revisitar alguns conceitos básicos do Bitcoin. Quando você transfere Bitcoin para outra pessoa, você cria uma transação e a transmite para a rede do 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 notar que o Bitcoin não tem um estado global como o Ethereum, particularmente a falta de um estado de conta; ele apenas possui dados de saída de transação. Cada saída de transação tem dois estados: ou foi gasto pelo destinatário ou permanece não gasto. As saídas de transação não gastas (UTXOs) são o que estamos familiarizados. Além da quantidade de BTC associada, cada saída de transação também possui um script anexado escrito em Bitcoin Script. Quem puder fornecer a prova correta (Testemunha) para este script pode gastar o UTXO.

O Script do Bitcoin é uma linguagem de programação baseada em pilha com uma série de opcodes. Os programas anexados aos UTXOs frequentemente consistem em vários opcodes, realizando cálculos com base na pilha e retornando resultados a ela. Muitos scripts comuns de Bitcoin existem desde o início do Bitcoin. Por exemplo, o script mais comum consiste em uma chave pública e um opcode que verifica a assinatura digital. Este opcode requer 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 o BitVM (1)]

Capacidades do Bitcoin Script

O que o Bitcoin Script 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).
• Realizar 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 Script Bitcoin 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 de bit a bit.
• Falta de códigos de operação para multiplicação e divisão.
• Não é possível concatenar elementos na pilha.
• Tem capacidade muito limitada para ler e verificar os dados de transação na cadeia. O Bitcoin Script não pode acessar diretamente a quantia de cada transação e não pode passar estado (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 mencionadas acima como "não permitidas" eram possíveis, mas certos opcodes foram posteriormente desativados 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 nós do Bitcoin e causar crashes. Satoshi desativou OP_CAT e outros opcodes por razões de segurança.

Então, o Bitcoin Script pode verificar SNARKs? Teoricamente, embora 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 4 MB. Embora possamos tentar operações aritméticas em grandes campos finitos, o custo seria proibitivamente alto. Por exemplo, no BitVM, a multiplicação de dois inteiros de 254 bits resultou em um tamanho de script Bitcoin de quase 8 KB. Além disso, sem o OP_CAT, o custo da verificação de provas de Merkle também é alto, pois isso requer operações semelhantes a loops.

Então, por que não simplesmente 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 dos interessados com perspectivas diferentes. Não há 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 de lançamento teórico para ativação real. O fator chave que permitiu o Taproot foi o fato de não alterar as suposições de segurança existentes e fazer 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, o Taproot reduz a quantidade de dados de script a serem revelados 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ê quiser acionar um determinado script, 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 a integração de recursos mais avançados, pode-se perguntar por que um código de operação dedicado para verificação SNARK ainda não foi introduzido. A diferença chave está na complexidade e no consenso necessários para o OP_SNARK. Ao contrário do Taproot, que tinha um design claro e direto que obteve amplo apoio, as propostas do OP_SNARK variam amplamente, tornando difícil mobilizar a comunidade em torno de uma única abordagem. Se implementado, cada nó do 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 do 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 o OP_SNARK exigiria codificação muito mais intrincada. Além disso, determinar quem avaliaria a ativação do OP_SNARK e alcançar consenso quando poucos entendem completamente suas complexidades adiciona camadas de dificuldade. Dadas essas dificuldades, é improvável que uma atualização do 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 em 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 com um impacto significativo, que poderia melhorar consideravelmente 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, há um crescente interesse dentro da comunidade Bitcoin em trazê-lo de volta.

A função do OP_CAT é direta - ele pega os dois principais elementos da pilha, os concatena e depois empurra o resultado de volta para a pilha. Embora isso possa parecer básico, tem o potencial de desbloquear melhorias substanciais na linguagem de script do Bitcoin. Por exemplo, os scripts atuais do Bitcoin não conseguem 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, o OP_CAT é uma atualização de opcode de baixo nível que pode levar a uma ampla gama de novas funcionalidades. Muitos apontaram que o OP_CAT poderia ser crucial na realização de vários objetivos. Uma questão chave é se o OP_CAT poderia ajudar na verificação SNARK dentro de scripts. A resposta é sim. Como a verificação de prova de Merkle é um passo em direção à validação de SNARKs baseados em FRI, o OP_CAT seria uma adição valiosa. No passado, os scripts projetados para verificação SNARK podem ter sido muito grandes para caber nos limites de tamanho de bloco do Bitcoin, mas o OP_CAT pode ajudar a simplificar esses scripts, tornando-os mais compactos.

OP_CAT tem sido discutido há anos, com uma crescente consciência do seu papel potencial na introspecção de transações. Uma das suas principais vantagens sobre outras propostas é que foi uma parte integrante do Bitcoin Script, o que poderia tornar mais fácil alcançar o consenso da comunidade. No entanto, a desvantagem é que ativar o OP_CAT poderia impactar negativamente os lucros de MEV (Valor Minerável Extraível) para alguns, o que levou a um debate contínuo dentro da comunidade sobre a sua reativação.

Em resumo, o Bitcoin poderia dar um passo em direção à verificação SNARK em scripts reintroduzindo opcodes simples como OP_CAT. Além disso, vale a pena mencionar uma proposta recente chamada "Great Script Restoration", 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 os seus efeitos nos operadores de nós Bitcoin. Para garantir que o Bitcoin permaneça resistente à censura e descentralizado, a comunidade se esforça para que o maior número possível de pessoas execute nós para validar transações. Se o Bitcoin implementasse a verificação de SNARK, não aumentaria significativamente o custo de operar um nó, o que não afetaria muito a segurança ou a resistência à censura do Bitcoin.

Atualmente, um bloco de Bitcoin pode conter até 4MB de dados, com novos blocos sendo minerados aproximadamente a cada 10 minutos. A maioria dos blocos é preenchida com scripts de 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 contexto, minha CPU Intel de 2020 leva cerca de 3,2 segundos para verificar um bloco de 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 principal. As 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 com transações de Bitcoin de forma eficiente.

Fiz uma pequena pesquisa perguntando aos utilizadores sobre o atraso máximo que aceitariam para um dispositivo de assinatura gerar uma prova, e muitas pessoas estavam 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 alterações ao design subjacente do Bitcoin, mas existem muitas aplicações que podem ser desenvolvidas sem alterar o próprio Bitcoin. Uma dessas aplicações que vale a pena mencionar são as Provas de Estado de Cadeia, que está relacionada com BitVM. Esta abordagem usa provas de conhecimento zero para validar a correção dos hashes de bloco.

Que impacto essa tecnologia tem no Bitcoin? Em primeiro lugar, as Provas do Estado da Cadeia podem reduzir bastante a carga de trabalho envolvida 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 ponta e vários dias em um dispositivo de nível Raspberry Pi. As Provas do 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 de “Provas de 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çalhos” 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 de SHA-256 duplo para cada cabeçalho para verificar a prova de trabalho associada. O ZeroSync utiliza STARKs para gerar essas provas de 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, como as provas da cadeia de cabeçalho não verificam as transações dentro dos blocos, eles só podem assumir que a blockchain com mais prova de trabalho (PoW) é válida e confiar nos clientes do Bitcoin para sincronizar os últimos blocos desta 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 existentes de nós completos do Bitcoin.

No entanto, embora as chances de tal ataque ter sucesso sejam baixas, se permitir que os atacantes roubem uma quantidade significativa de BTC, as provas de cadeia de cabeçalho não seriam consideradas uma solução completamente segura. Para verificar o estado completo da cadeia, precisamos garantir que todo o conteúdo do bloco Bitcoin seja válido, incluindo verificações de assinatura 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 Bitcoin gera cerca de 7 GB de dados de bloco por mês, com dados históricos ultrapassando 650 GB - e, na prática, essa figura pode ser de 2 a 3 vezes maior.

Agora, vamos olhar para BitVM. BitVM permite que o Bitcoin verifique qualquer tarefa computacional, fornecendo uma forma ideal de realizar a verificação SNARK sem modificar o protocolo. BitVM supera as limitações de tamanho do script do Bitcoin usando dois métodos. Primeiro, alavanca a estrutura do script Taproot MerkleTree. Segundo, utiliza um esquema de armazenamento KV que pode ser acessado através de scripts individuais, facilitando conexões com um grande número de programas de script. No entanto, o protocolo do Bitcoin não impõe a integridade deste esquema de armazenamento KV. BitVM aborda isso empregando provas de fraude para detectar Provers maliciosos. Se um Prover fizer reivindicações inválidas ou usar um armazenamento KV defeituoso, 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. As mudanças de protocolo não são alcançáveis a curto prazo, refletindo tanto as forças quanto as limitações da descentralização e segurança do Bitcoin. O potencial de SNARKs e STARKs está gerando considerável entusiasmo dentro da comunidade. 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 a instrução OP_CAT é outra via a explorar, mas é necessário demonstrar que os benefícios da reativação superam os riscos e identificar quais instruções simples poderiam facilitar a verificação de SNARK ou funções semelhantes em scripts Bitcoin. Em última análise, a comunidade do Bitcoin visa melhorar a praticidade da tecnologia e apoiar mais casos de uso acionáveis.

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

Aviso legal：

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