Conhecimento zero no Bitcoin: provas e transferências blindadas

Curiosidade

1. Como um valor criptografado pode se mover em uma cadeia pública sem alterar as regras de consenso?
2. O que um anulador revela sobre uma nota gasta, e o que ele oculta?
3. Por que um protocolo dependeria de um indexador em vez de nós completos para validar seu estado central?

Explorar

Parte IBitcoin blindado: transferências privadas sem soft fork

1. Clara Shikhelman, Mikhail Komarov e Aleksei Moskvin publicaram “Shielded Bitcoin” em 24 de setembro de 2026. O artigo de 56 páginas propõe um design que utiliza a arquitetura dos pools Sapling e Orchard do Zcash para uso no Bitcoin. O valor é mantido na forma de notas criptografadas, em vez de UTXOs padrão. Ao gastar uma nota, é revelado um anulador para impedir o gasto duplo, mas esse identificador não faz referência à nota específica ou à sua fonte original.
2. Cada transferência consiste em uma transação comum do Bitcoin com uma saída OP_RETURN. Essa saída contém um envelope que abriga uma prova de conhecimento zero Groth16, com tamanho aproximado de 192 bytes. A prova demonstra que a transferência é válida e balanceada sem expor os dados subjacentes. Um envelope padrão com duas entradas e duas saídas ocupa cerca de 610 bytes, e a saída OP_RETURN cerca de 625 vB. As regras de consenso do Bitcoin ignoram completamente esses dados; eles são tratados como carga útil não utilizável.
3. Como os nós completos não validam o conteúdo do OP_RETURN, os indexadores precisam reproduzir esses “envelopes” em ordem de bloco para reconstruir a árvore de notas, o conjunto de anuladores e as raízes Merkle. Se uma transferência inválida aparecer em um bloco, os indexadores simplesmente a ignoram em vez de rejeitar o bloco. Isso transfere a verificação dos nós completos para o software dos indexadores. Um indexador desonesto pode fornecer informações desatualizadas ou incompletas, mas não pode retirar fundos, e qualquer pessoa pode executar seu próprio indexador.
4. O design oculta valores, remetentes, destinatários e posições no grafo da análise de cadeia. No entanto, o tempo, as taxas, a estrutura dos transportadores de dados e a contagem de entradas/saídas permanecem visíveis na cadeia. O relay dessas transações depende do limite padrão maior para transportadores de dados no Bitcoin Core v30, uma mudança de política em vez de um upgrade de consenso. Se muitos operadores definirem limites mais rígidos, tais transações seriam mais difíceis de retransmitir, embora mineradores dispostos a aceitá-las ainda pudessem incluí-las.
5. O artigo deixa explicitamente os mecanismos de peg-in e peg-out fora do escopo deste design inicial. Os autores planejam construir esses componentes com base no Bitcoin PIPEs v2, usando criptografia de testemunha para travar as chaves privadas atrás de declarações criptográficas. Essa abordagem permite a programabilidade por meio das assinaturas Schnorr existentes, em vez de novos opcodes. Atualmente, o projeto não possui implementação, usuários ou fundos em circulação; permanece como uma especificação teórica.
6. O design tem limitações conhecidas. O Groth16 requer um trusted setup único, seguro se pelo menos um participante da cerimônia for honesto. Um novo pool começa com um conjunto de anonimato zero, o que torna os usuários iniciais mais fáceis de distinguir. Uma transferência é reportada em cerca de 700 vB, várias vezes maior do que um pagamento comum. As provas se baseiam em curvas elípticas que um grande computador quântico poderia quebrar. E até que os indexadores possam provar seu estado de forma barata, as carteiras leves devem confiar no indexador consultado, embora ele não possa tomar seus fundos.

Parte IIProvas de conhecimento zero no Bitcoin hoje

7. O Script do Bitcoin foi projetado para simplicidade e segurança, limitando sua capacidade de executar código arbitrário. Uma prova de conhecimento zero padrão, como um SNARK Groth16, requer aritmética em curvas elípticas baseada em emparelhamento, que o conjunto atual de opcodes do Bitcoin não consegue realizar a um custo razoável. Essa lacuna computacional significa que a própria rede não pode verificar essas provas nativamente, sem um soft fork ou um gasto significativo de recursos por transação.
8. Os protocolos no estilo BitVM resolvem isso por meio de verificação otimista. Em vez de verificar cada prova imediatamente, eles assumem que ela está correta e só acionam uma verificação dispendiosa se surgir uma disputa. Se ninguém questionar a transição de estado dentro de um determinado período, ela é aceita como válida. A segurança se baseia em incentivos: os operadores depositam garantias que perdem caso trapaceiem, e qualquer pessoa pode questioná-las.
9. A ponte Clementine da Citrea foi lançada na mainnet em janeiro de 2026, utilizando essa arquitetura BitVM2. Seu caminho de resolução de disputas verifica uma prova Groth16 com um verificador Script de aproximadamente 1 GB (abaixo das estimativas iniciais de cerca de 3 GB), dividido em blocos que são executados somente quando uma contestação é feita. Esse design permite que transições complexas de estado sejam protegidas pelo Bitcoin, sob a premissa de que apenas uma parte envolvida seja honesta, sem exigir que cada nó completo execute as pesadas verificações criptográficas para transações rotineiras.
10. O projeto Glock da Alpen demonstrou uma abordagem alternativa que utiliza circuitos embaralhados, alcançando uma rede de teste em julho de 2026. O Glock usa circuitos embaralhados para tornar a verificação de provas durante disputas muito mais barata na cadeia de blocos. Ele ainda se baseia em disputas, mas com um impacto muito menor na cadeia de blocos; ambas as abordagens reconhecem que a verificação nativa por meio do Script para criptografia avançada continua sendo excessivamente cara para uso geral.
11. A validação do lado do cliente oferece outro caminho no qual as provas de propriedade são verificadas pelos usuários ou por indexadores, em vez da camada de base. Protocolos como RGB e Taproot Assets dependem dos participantes para verificar localmente as provas de propriedade. Da mesma forma, os designs do Shielded Bitcoin envolvem indexadores que reexecutam os envelopes de transação para reconstruir as árvores de notas; transferências inválidas são ignoradas pelo consenso, mas podem ser detectadas por softwares de monitoramento que executam toda a lógica de verificação fora do nó.
12. Esses sistemas apresentam trade-offs específicos. O Groth16 requer uma configuração confiável, na qual uma cerimônia deve garantir que ninguém retenha segredos perigosos que possam invalidar as provas. As transações em disputa nos sistemas otimistas são grandes e complexas, criando desafios de relé. Além disso, as curvas adequadas para emparelhamento por trás do Groth16, como a secp256k1 do próprio Bitcoin, são vulneráveis a um computador quântico avançado; assim, um computador quântico poderia forjar provas e quebrar a criptografia baseada em ECDH, embora as provas do Groth16 em si não revelem nenhum segredo.

Fatos-chave

Exercício nove, seis, três, um

Verificação de fatos

Datas, números e afirmações verificados com as fontes publicadas listadas abaixo.

• Shikhelman, Komarov & Moskvin, 'Shielded Bitcoin' ([alloc] init, September 24, 2026)
• D. Hopwood et al., Zcash Protocol Specification (Sapling and Orchard)
• Bitcoin Core v30 release notes
• news.bitcoin.com coverage of Shielded Bitcoin (2026)
• R. Linus et al., 'BitVM2: Bridging Bitcoin to Second Layers' (2024)
• Citrea documentation and mainnet announcement (2026)
• Alpen, 'Glock is here' (July 2026)