MSTR Cat

Blockchain/Nível IV · Protocolo a fundo/4.2 Atualizações/Lição 6

A fronteira criptográfica: criptografia de testemunha e PIPEs

Como trancar uma chave dentro de uma prova quando o opcode nunca chega

MateriaisUma cópia do BIP-119 e BIP-347Acesso a um explorador de blocos com recursos de depuração de scriptsUm caderno para rastrear os status das propostasUma cópia do IACR ePrint 2026/186

Curiosidade

  1. Por que o Bitcoin consegue verificar uma assinatura, mas não restringir para onde a moeda resultante irá em seguida?
  2. Quanto custa provar que se conhece um segredo sem revelar o próprio segredo?
  3. Como os protocolos mantêm a segurança quando as regras subjacentes permanecem estáticas e imutáveis?

Explorar

    Parte IA fronteira criptográfica: covenants e criptografia de testemunhas

  1. O Bitcoin Script é deliberadamente limitado. Ele pode verificar se uma assinatura corresponde a uma chave pública, mas não consegue analisar o destino das moedas após elas serem gastas. Essa restrição mantém o Script simples e previsível. No entanto, ela também impede certos designs nos quais as condições de gasto dependem de estruturas de transações futuras.
  2. A proposta de Jeremy Rubin para OP_CHECKTEMPLATEVERIFY (BIP-119) aborda essa lacuna. O opcode permitiria que um script exigisse que a transação de gasto correspondesse a um modelo comprometido, fixando seus outputs e certos outros campos. Isso habilita covenants não recursivos: regras sobre para onde as moedas podem ir em seguida, como bloquear fundos em cofres ou restringir os caminhos de resgate. Ele permanece inativo e sujeito a debates contínuos na comunidade Bitcoin.
  3. Uma proposta separada, OP_CAT (BIP-347), foca na concatenação de dados na pilha em vez de impor restrições ao destino diretamente; no entanto, combinado com assinaturas Schnorr, também pode habilitar covenants. Essa operação simples permite a criação de construções criptográficas complexas, incluindo assinaturas em formato de árvore que expressam políticas de multisignatura muito grandes de maneira compacta. Ela também facilita as assinaturas Lamport resistentes ao modelo pós-quântico, ao permitir que hashes e valores sejam manipulados diretamente dentro do mecanismo de script.
  4. Além de novos opcodes, pesquisas exploram a criptografia de testemunhas como um caminho alternativo para a programabilidade. A criptografia de testemunhas permite que um remetente bloqueie dados de modo que apenas quem puder provar a posse de um segredo específico (uma testemunha) possa desbloqueá-los. Isso poderia, teoricamente, permitir que as chaves do Bitcoin sejam reveladas somente após a comprovação de uma afirmação, sem que a rede precise verificar o cálculo diretamente.
  5. Existem construções iniciais de criptografia de testemunhas na literatura acadêmica, mas elas continuam impraticáveis para o uso no Bitcoin. Ainda não existe uma construção prática para declarações gerais: os esquemas conhecidos são enormes e se baseiam em suposições criptográficas que ainda não gozam de ampla confiança. Embora as bases teóricas sejam sólidas, a lacuna técnica entre um protótipo conceitual e um protocolo pronto para uso prático continua sendo significativa.
  6. O trade-off é claro: os covenants adicionam expressividade, mas introduzem novas regras de consenso que exigem análise cuidadosa; a criptografia de testemunhas oferece privacidade e flexibilidade, mas impõe altos custos de armazenamento e processamento. Ambas as abordagens buscam expandir as capacidades do Bitcoin sem abandonar seu modelo de segurança central de emissão fixa e previsível, além de um poder de script limitado.

    7. Parte IIEntrada e saída de bitcoin: PIPEs e criptografia de testemunha

  7. O Shielded Bitcoin, detalhado na lição anterior, lida com transferências privadas dentro de seu próprio sistema de notas. Ele deixa o peg-in e o peg-out fora do escopo: como mover valor do bitcoin comum e transparente para a camada protegida, e vice-versa. O plano de design para essas pontes depende de um mecanismo chamado criptografia de testemunha, especificamente os Bitcoin PIPEs v2 (IACR ePrint 2026/186, fevereiro de 2026).
  8. A criptografia de testemunha trava dados atrás de uma afirmação matemática. Nesse contexto, uma chave privada do bitcoin é criptografada de modo que só pode ser descriptografada se alguém apresentar um witness válido — uma prova de que a afirmação é verdadeira. O texto cifrado é publicado off-chain, e a chave interna permanece inacessível para quem não conseguir produzir o witness correspondente.
  9. O mecanismo transfere a programabilidade do consenso para a criptografia. Em vez de exigir novos opcodes ou soft forks para impor condições complexas de gasto, a lógica fica inteiramente dentro do esquema de criptografia. Quem apresentar um witness válido, como uma prova SNARK, recupera a chave privada e gasta as moedas usando uma assinatura Schnorr comum. Para as regras de consenso do Bitcoin, isso é apenas uma transação padrão; a complexidade fica invisível.
  10. Essa abordagem pode emular restrições no estilo de covenants, como CheckTemplateVerify ou mecanismos de cofre, sem alterar o protocolo. As condições são impostas pela incapacidade de descriptografar a chave, a menos que critérios específicos sejam atendidos no witness. Ela oferece um caminho para condições avançadas de gasto que permanecem compatíveis com as regras de validação existentes do Bitcoin, desde que a criptografia subjacente se mantenha firme.
  11. O principal obstáculo é a escala. O artigo de fevereiro de 2026 estimou cada texto cifrado em cerca de 338 terabytes; trabalhos posteriores dos autores afirmam cerca de 10 terabytes, o que ainda é impraticável para armazenamento e distribuição. Não existe nenhuma implementação, portanto essas são apenas estimativas, e se os PIPEs podem ser implantados de alguma forma continua sendo uma questão de pesquisa em aberto.
  12. Isso ainda está em fase de pesquisa, não é um recurso implementado. Não há datas definidas para implantação, e as cifras divergentes sobre o tamanho destacam a incerteza desse campo. Até que os textos cifrados diminuam suficientemente, a criptografia de testemunha serve como uma ponte teórica entre o livro-razão transparente do Bitcoin e compromissos criptográficos complexos, em vez de ser uma ferramenta funcional para os usuários.

Fatos-chave

  • OP_CHECKTEMPLATEVERIFY (BIP-119) propõe um mecanismo de covenant para restringir os destinos futuros das moedas.
  • OP_CAT (BIP-347) permite a concatenação de pilhas, suportando assinaturas em formato de árvore e assinaturas baseadas em hash (Lamport).
  • A criptografia de testemunha bloqueia os dados por trás da prova de uma testemunha secreta, sem revelar o segredo.
  • Ainda não existe uma construção prática de criptografia de testemunhas para declarações gerais.
  • Os covenants permanecem como propostas inativas, sujeitas a debates por consenso.
  • As limitações do Bitcoin Script impedem, por design, muitas categorias de ataques.
  • Os Bitcoin PIPEs v2 usam criptografia de testemunha para travar chaves privadas atrás de afirmações matemáticas.
  • Para recuperar a chave, é necessário apresentar um witness válido, como uma prova SNARK.
  • Os gastos são feitos por meio de uma assinatura Schnorr comum assim que a chave é recuperada.
  • O mecanismo emula covenants sem exigir novos opcodes ou soft forks.
  • Os tamanhos estimados do texto cifrado caíram de aproximadamente 338 TB (no artigo original) para cerca de 10 TB (em afirmações posteriores), ainda sendo impraticáveis.
  • Os planos de peg-in e peg-out do Shielded Bitcoin dependem dessa infraestrutura de criptografia de testemunha.

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

9ReunirListe 9 restrições técnicas ou características do Bitcoin Script que definem suas capacidades e limites atuais.
6AgruparAgrupe os 9 em 6 de acordo com o que cada um permite ou impede.
3DestilarReduza os 6 grupos a 3 razões principais pelas quais é difícil expandir o Bitcoin Script, apesar dos benefícios teóricos claros.
1CristalizarEscreva 1 frase sobre a tensão fundamental entre adicionar programabilidade e manter a estabilidade do consenso em um sistema descentralizado.

Verificação de fatos

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

Abrir na academia interativa →

EN ES ZH JA KO RU DE FR MS