OP_CAT está acontecendo? A proposta de convênios acaba de receber o número BIP nº 347. Mas antes de nos aprofundarmos, vamos explorar o que são convênios e por que os Bitcoiners podem desejá-los.
O Bitcoin é um estado ideal de dinheiro eletrônico digital ou queremos mais de nossas moedas na rede?
Arranhar a superfície: limitações dos scripts Bitcoin
Para entender propostas de pacto como OP_CAT, é crucial entender as limitações fundamentais do Bitcoin Script como ele é hoje. Nos bastidores, o Bitcoin permite a criação de contratos inteligentes básicos por meio de códigos que definem as regras para bloqueio e desbloqueio de fundos. No entanto, o Bitcoin Script, como linguagem de programação, é bastante limitado à lógica básica que entra em ação apenas ao mover moedas em uma nova transação.
No Bitcoin hoje não há como pré-configurar ou ditar os caminhos de transação de suas moedas, ou quão rápido as moedas podem se mover no momento em que estão sendo bloqueadas (além de fluxos de trabalho hacky usando PSBT, transações de bitcoin parcialmente assinadas, que não podem ser adequadamente incluir taxas de transação, provar a exclusão se não for utilizado ou impedir a transmissão posterior).
Essa simplicidade, embora fundamental para o modelo de segurança do Bitcoin, introduz limitações significativas na capacidade da linguagem de script de suportar até mesmo contratos inteligentes básicos.
Modelo de Execução Linear
Uma limitação do Bitcoin Script é o seu modelo operacional onde os opcodes são executados sequencialmente sem loops.
Neste exemplo de transação P2PKH, você pode ver como o script é executado linearmente: duplicando a chave pública, fazendo hash para um endereço, verificando o hash em relação ao script de bloqueio e, finalmente, verificando a assinatura em relação à chave pública.
A ausência de looping significa que os scripts não são Turing completos e têm garantia de encerramento, evitando problemas como loops infinitos que poderiam interromper ou desacelerar significativamente a rede. Embora essa escolha de design permita que o uso de recursos seja limitado estaticamente, ela também limita a capacidade do Script de gerenciar fluxos de trabalho complexos.
Falta de aritmética básica
O Bitcoin Script tem pouco menos de 100 opcodes não triviais e, surpreendentemente, não há capacidade de multiplicar, dividir ou combinar objetos na pilha. Como muitos usuários interessados em OP_CAT saberão, Satoshi desativou vários opcodes no Bitcoin em 2010, incluindo OP_OR, OP_MUL (multiplicar), OP_DIV (dividir) e OP_CAT (concatenar), entre outros. Os opcodes desativados foram removidos porque suas implementações originais apresentavam vulnerabilidades exploráveis que poderiam comprometer a segurança da rede. Mas a ausência desses opcodes dificulta a matemática básica, que pode ser útil em cenários simples, como o cálculo de taxas de transação em um contrato.
Falta de visibilidade dos dados de transação
Superficialmente, acho que a maioria das pessoas assume que os contratos inteligentes Bitcoin são capazes de ver valores e quaisquer outras partes dos dados de transação, uma vez que esta informação já está publicamente visível no blockchain. Mas, contrariamente a esta suposição, os contratos de Bitcoin não são capazes de definir condições de gasto com base nos dados de transação, porque o Bitcoin Script tem uma capacidade muito limitada de ver os dados de transação.
Se o script tivesse a capacidade de interpretar mais detalhes nos dados de transação, poderíamos construir contratos muito mais robustos que poderiam fazer todas as coisas divertidas, como impor condições de gastos específicas, criar transações em vários estágios e habilitar recursos de segurança mais avançados, como cofres.
O que fazemos sobre isso?
Sabemos que o Bitcoin tem essas limitações e, ao longo dos anos, muitas propostas diferentes foram discutidas para introduzir (ou, em alguns casos, reintroduzir) essa funcionalidade. Experimentos mais amplos com Bitcoin Script, como Simplicity e outros, visam fornecer uma alternativa às restrições baseadas em pilha. Opcodes como OP_MULTISHA256, OP_LESS e OP_LE32TOLE64 visam atualizar as habilidades aritméticas do Bitcoin. Propostas como OP_CTV e OP_CAT que tratam de opcodes de introspecção são agrupadas sob o termo convênios.
Então, qual é exatamente a diferença entre contratos inteligentes e acordos de novos prazos?
Contratos Inteligentes vs. Convênios
Os contratos inteligentes são transações autoexecutáveis que transferem fundos sem intermediários. No Bitcoin hoje, os contratos inteligentes estão limitados ao ato de bloquear e desbloquear bitcoin com Bitcoin Script. Os convênios visam aprimorar a funcionalidade dos contratos inteligentes do Bitcoin, permitindo que os usuários controlem como seus fundos serão gastos em transações futuras.
Ao permitir que o Script interprete os dados da transação, criamos efetivamente uma maneira de esses dados serem usados na lógica do contrato.
Estes são apenas alguns dos opcodes de introspecção mais interessantes para funcionalidade de convênios:
OP_TXHASH: Fornece o hash das entradas (ou saídas) de uma transação e dá ao Script a capacidade de verificar e impor condições com base nos dados da transação.
OP_CSFS + OP_CAT: Os dois juntos permitem que os scripts verifiquem assinaturas em relação a quaisquer dados, não apenas à transação em si. Isso significa que o Script pode verificar condições com base em dados de transações ou informações externas, ampliando as possibilidades de validação dentro de scripts Bitcoin.
Esses dois opcodes são intencionalmente amplos, permitindo processos complexos de validação e recursos de introspecção. Outros têm um âmbito mais restrito e são concebidos para serem uma forma mais limitada de pactos.
OP_CHECKTEMPLATEVERIFY (CTV): Permite que uma saída de transação incorpore um modelo de uma transação de gastos futura, permitindo convênios de forma mais restrita.
OP_VAULT: permite uma forma específica de convênio usada para “cofre”, que permite aos usuários especificar um destino de transação, mas não mover moedas, exceto após um atraso.
Depois, há o OP_CAT por si só, que não é diretamente um opcode de introspecção…
OP_CAT: permite que o script concatene dois elementos na pilha, o que é útil para combinar diferentes informações em um script.
OP_CAT não parece ter nenhuma habilidade de introspecção, então o que está acontecendo aqui?
OP_CAT: Desvendando todas as possibilidades
Introspecção de transação
Em 2021, Andrew Poelstra escreveu sobre truques de introspecção OP_CAT em uma postagem de blog. Ele forneceu exemplos específicos, mas presumiu que os leitores tinham conhecimento prévio de técnicas semelhantes. Aqui, tentarei simplificar essa explicação para melhor compreensão.
No Bitcoin Script, existem apenas três opcodes principais que permitem a introspecção dos dados da transação: CHECKLOCKTIMEVERIFY, CHECKSEQUENCEVERIFY e CHECKSIG. Além disso, existem variantes como CHECKSIGVERIFY, CHECKSIGADD, CHECKMULTISIG e CHECKMULTISIGVERIFY, que são essencialmente variações menores de CHECKSIG. Os dois primeiros permitem apenas ver se a verificação foi verificada, fornecendo uma funcionalidade bastante restrita. CHECKSIG é semelhante, mas a diferença aqui é que permite capturar a assinatura e a chave pública na pilha. Interessante.
Tradicionalmente, pensamos na concatenação como uma função que une dois itens, mas também podemos usá-la para separar ou dividir um item, neste caso – a assinatura em um par (r, s).
Como derivamos a funcionalidade OP_SPLIT do OP_CAT?
“Se você tiver algum objeto grande, poderá dividi-lo em dois, pedindo ao usuário que gaste algum tempo para fornecer as duas peças. Você os CAT juntos e basicamente verifica a igualdade. Você sempre pode inverter todas as operações dessa maneira. Com o CAT sozinho você pode separar assinaturas.” - Andrew Poelstra, TABConf 2021
O que esta acontecendo aqui?
Ao exigir que o usuário forneça a assinatura, a chave pública e a transação, você pode dividir a assinatura em suas partes componentes e, em seguida, verificar cada parte de forma independente em relação aos dados da transação. Esta técnica pode ser vista como uma forma de divisão ou combinação, pois valida que a assinatura e a chave pública são de facto os componentes de uma transação válida.
Como tudo isso nos traz introspecção?
“No Taproot, onde temos assinaturas Schnorr usando OP_CAT e o opcode de verificação de assinatura Schnorr, descobrimos que é possível obter uma forma de aliança não recursiva onde você literalmente obtém um hash de transação. Nem mesmo um hash de transação mutilado engraçado, mas um hash SHA2 literal de todos os dados de transação na pilha.” - Andrew Poelstra, TABConf 2021
Poelstra continua demonstrando como você pode obter um hash SHA2 para entradas ou saídas de transações deixadas na pilha. Iremos pular a matemática da lua aqui, mas a implicação é que com OP_CAT podemos restringir partes de uma transação como um requisito do script de desbloqueio. Podemos restringir o endereço de envio ou o valor enviado dessa transação, onde o hash da transação serve como chave para desbloqueá-la.
Cofres
Usar as mesmas técnicas nos dá uma introspecção da transação e rapidamente nos dá uma versão básica dos cofres. Seguindo a lógica descrita no blog de Poelstra, um desenvolvedor chamado Rijndael provou que podemos fazer isso apenas com OP_CAT em sua implementação do Purrfect Vaults.
“Reconstruir um TXID na pilha para examinar transações anteriores foi realmente mais fácil do que eu esperava.” -Rijndael
Com os cofres, os usuários especificam o próximo endereço para onde seus fundos devem ir, fornecendo mecanismos para recuperação de fundos em caso de comprometimento da chave e reduzindo o incentivo ao roubo de chaves privadas.
Árvores Merkle para roteiro
No Bitcoin hoje, Merkle Trees são a estrutura de dados usada para verificação de dados, sincronização e mais ou menos “encadeamento” das transações e blocos do blockchain. O opcode OP_CAT, que permite a concatenação de duas variáveis de pilha, quando usado junto com hashes SHA256 de chaves públicas, facilita um processo direto de verificação de árvore Merkle para scripts. Esta abordagem, proposta inicialmente por Pieter Wuille em 2015, foi implementada com sucesso na rede Liquid.
Imagine uma estrutura de árvore repleta de diversas condições de gastos, como pré-imagens de hash, timelocks e chaves públicas, conhecidas como assinaturas de árvore.
Assinaturas de árvores
OP_CAT permite a criação de assinaturas de árvore que:
“… Fornece um script de múltiplas assinaturas cujo tamanho pode ser logarítmico no número de chaves públicas e pode codificar condições de gasto além de n-de-m. Por exemplo, uma transação com tamanho inferior a 1 KB poderia suportar assinaturas de árvore com mil chaves públicas. Isso também permite condições lógicas generalizadas de gastos.” — Autor do BIP, Ethan Heilman, na lista de discussão bitcoin-dev
Isso permitiria a validação de qualquer conteúdo com hash dentro da árvore, mantendo a integridade e a confiabilidade dos dados sem adicionar volume ou inchaço desnecessário ao blockchain.
O que há de interessante nisso tudo?
Convênios Recursivos
Se você tiver a capacidade de examinar uma transação e aplicar restrições a determinadas partes dela, poderá configurar condições que se aplicam a diversas transações, criando efetivamente uma cadeia de restrições contínuas. Este conceito é chamado de aliança recursiva. OP_CAT é uma proposta única porque nos dá muito poder para apenas 10 novas linhas de código. Ele tem a capacidade de resolver todas as três limitações iniciais que abordamos no início da postagem: visibilidade dos dados da transação, melhor funcionalidade matemática e seu modelo de execução linear.
Embora OP_CAT possa parecer simples à primeira vista, ele revela um potencial significativo quando aproveitado de forma criativa. Ele serve como um alicerce para ainda mais funcionalidades muito além do escopo desta discussão, como as assinaturas pós-quânticas de Lamport.
Isso é seguro?
Antes de OP_CAT ser inicialmente removido, quando combinado com OP_DUP (duplicado) e usado repetidamente para duplicar um valor inicial de 1 byte na pilha, o uso de memória poderia explodir. Isso poderia ter sido usado como um ataque de negação de serviço (DoS) como resultado do aumento do consumo de memória. A nova proposta evita trivialmente esse ataque, impondo um limite de 520 bytes nos elementos da pilha.
Existe o perigo de um contrato durar para sempre?
Se com isso queremos dizer, OP_CAT altera o modelo de execução do Script para significar que ele não limita mais estaticamente o uso de recursos (como uma função linear do tamanho do Script)? Não.
Os convênios criariam um mercado para outras moedas além do Bitcoin?
Se você tiver uma aliança recursiva, sim, poderá construir tecnicamente aplicativos complexos de camada 2, incluindo NFTs, exchanges descentralizadas e gatos quânticos. No entanto, fazer isso não é trivial. É difícil ver algum mercado sério fazer isso.
Você pode “manchar” moedas permanentemente usando CAT?
No caso de moedas coloridas e NFTs, ao emitir esses ativos, o usuário efetivamente “queima” um satoshi, marcando-o de uma forma que significa propriedade do ativo da “camada 2”. Este processo é conhecido como moedas de “contaminação”. Mas apenas o proprietário de uma moeda pode marcá-la, e as carteiras Bitcoin não a reconhecerão mais (a menos que seus autores adicionem explicitamente um código para permitir isso). As moedas resultantes não seriam aceitas pelas carteiras bitcoin. Provavelmente eles seriam aceitos por carteiras criptocat ou algo parecido, mas isso é irrelevante para a maioria dos usuários de bitcoin.
Isso criaria um problema de MEV no Bitcoin?
Um ponto chave de distinção entre Bitcoin e Ethereum é a visibilidade da transação. Ao contrário do Ethereum, nem todos os aspectos do contrato são necessariamente transparentes, o que significa que os mineradores de Bitcoin não têm a mesma capacidade de ver o estado do contrato interno e administrá-lo.
A principal preocupação do OP_CAT por Bitcoiners com mentalidade econômica é o potencial de Miner Extractable Value (MEV). Conforme discutido mais extensivamente em meu post anterior sobre o assunto. Muitos usuários estão preocupados com o fato de que, se tornarmos tecnicamente possíveis os contratos da camada 2, o MEV se tornará inevitável. Mas isso é verdade? Especificamente, a viabilidade técnica das moedas da camada 2 no Bitcoin implica sua inevitável criação e adoção?
Você poderia imaginar a construção de contratos de swap simples ou NFTs comparativamente ineficientes, mas construir algo tão complexo como DEXs com criadores de mercado automáticos parece extremamente improvável e nunca foi algo que vimos na Liquid, apesar da “possibilidade técnica” para isso.
Então o OP_CAT é realmente perfeito?
Dificilmente, longe disso. Algumas pessoas adorariam ver acordos recursivos, enquanto outras simplesmente não querem ver o Bitcoin mudar.
Uma facção de Bitcoiners, “ossificacionistas”, defende a preservação do Bitcoin em seu estado atual e vê quaisquer atualizações de protocolo com ceticismo. Estão particularmente preocupados com o facto de mudanças significativas, como a introdução de acordos, poderem minar a descentralização da rede. O argumento deles depende da crença de que é melhor seguir fielmente a visão original do Bitcoin. A ironia é que OP_CAT inicialmente fazia parte do Bitcoin alimenta um contra-argumento. Alguns acreditam que trazer o OP_CAT de volta poderia realmente realinhar o Bitcoin com a visão inicial de Satoshi.
Se você quiser ver alguns dos recursos de segurança que as cláusulas recursivas poderiam tornar possíveis, OP_CAT seria bom, mas definitivamente não tão bom quanto uma linguagem de script estilo Lisp completa. O problema aqui é que esta seria uma grande mudança para o Bitcoin, que provavelmente não se firmará tão cedo.
Ou talvez você esteja do outro lado e prefira a simplicidade do não recursivo como OP_CTV ou OP_VAULT. As cláusulas não recursivas são mais simples e fáceis de raciocinar, sem o risco de criar uma cadeia descontrolada de restrições.
E se alguma versão de pactos recursivos fosse inevitável?
Ao longo dos anos, os desenvolvedores notaram que quase qualquer extensão da lógica de validação de transação poderia ser usada para emular a funcionalidade do OP_CAT.
No universo Script, existem dois domínios, com base no tamanho dos elementos da pilha. Para elementos de pilha maiores que 4 bytes, você pode comparar a igualdade, interpretar como uma chave uma assinatura ou fazer hash. Para elementos de pilha menores ou iguais a 4 bytes, você pode tratá-los como objetos para fazer aritmética ou ramificação. Com um processador RISC-V rodando em um BitVM, você pode fazer literalmente qualquer coisa. Qualquer coisa que permita emular OP_CAT, dividir elementos da pilha ou concatená-los reúne esses dois domínios, para que você possa “fazer qualquer coisa” com o Script.
Pesquisadores como Andrew Poelstra esperam que possamos fazer acordos recursivos com praticamente qualquer novo código de operação. Se for verdade, isso seria uma justificativa para trabalhar no sentido de fazê-los bem.
OP_CAT é o caminho provável para os convênios?
Se os acordos não são apenas interessantes, mas inevitáveis, como podemos garantir que sejam implementados de tal forma que faça com que mais usuários de Bitcoin enviem sem confiança, como Satoshi originalmente imaginou? Embora os ossificacionistas permaneçam divididos, o OP_CAT continua a ascender como um forte concorrente no debate sobre os pactos.
OP_CAT não é o cinzel mais elegante, mas é aquele com a melhor relação entre potência e complexidade, o que permitiria aos desenvolvedores criar alguns novos recursos incríveis.
Este é um post convidado de Kiara Bickers. As opiniões expressas são inteiramente próprias e não refletem necessariamente as da BTC Inc ou da Bitcoin Magazine.
Fonte: Revista Bitcoin
A postagem OP_CAT: A solução purr-fect para convênios? apareceu primeiro em Crypto Breaking News.