O artigo "Ressurreição" foi eliminado pelo Código de Operação Satoshi Nakamoto?, leia-se OP_CATSoft Fork

Artigo original de Jaleel, BlockBeats

Na base de código do Bitcoin, um código de operação “OP _CAT” que foi excluído por Satoshi Nakamoto e foi selado pela história por um longo tempo pode ser “ressuscitado”.

Em torno do Código de Operação OP_CAT, o projeto Bitcoin Non-fungible Token Taproot Wizards lançou uma nova série Non-fungible Token Quantum Cats. Embora o termo OP_CAT não se refira ao conhecido “gato”, o Taproot Wizard usou a imagem de um gato para lançar um novo token não fungível chamado Quantum Cats, usando a cultura de memes para ajudar OP_CAT a criar impulso. Leitura relacionada: “Bitcoin “Quantum Cat”: Sem contrato inteligente, como conseguir a mudança dinâmica de inscrições?”

OP_CAT, o Código de Operação que já foi removido por Satoshi Nakamoto da linguagem de script Bitcoin, agora foi trazido de volta à mesa para discussão, e alguns desenvolvedores de Bitcoin querem “ressuscitar” esse Código de Operação e abrir caminho para o Bitcoin implementar o Smart Contract através de um soft fork de 13 linhas de código. Impulsionado pelos desenvolvedores do Bitcoin e criado impulso na imagem de um meme de gato, o calor e a discussão sobre OP_CAT atingiram novos patamares.

O Código de Operação de “Ressurreição” excluído por Satoshi Nakamoto

Códigos de operação, também conhecidos como instruções ou funções, são os blocos de construção básicos da linguagem de script Bitcoin. Historicamente, alguns Operation Code foram removidos de versões anteriores do Bitcoin devido a preocupações com possíveis vulnerabilidades em implementações de clientes, sendo OP_CAT Operation Code um deles.

OP_CAT era originalmente parte do conjunto de comandos oficial do Bitcoin, permitindo a junção de cordas, emendando dois elementos em um. No entanto, como uma vulnerabilidade crítica encontrada no Código de Operação, como OP_LSHIFT, pode causar qualquer falha de BitcoinNode, há uma preocupação de que OP_ CAT Operation Code possa fazer com que os elementos da pilha cresçam exponencialmente, o que pode levar a um aumento exponencial no uso de memória e no tamanho do script.

Portanto, por uma abundância de cautela, Satoshi Nakamoto removeu o OP_CAT em 15 de agosto de 2010. Estes Código de Operação removidos são muitas vezes referidos como “desativados”, mas isso não é preciso, pois são completamente removidos do protocolo, tornando o Código de Operação indisponível para qualquer pessoa que use o Bitcoin.

Em outubro de 2023, o desenvolvedor do Bitcoin Core, Ethan Heilman, e o engenheiro de software principal da Botanix Labs, Armin Sabouri, lançaram em conjunto um rascunho da Proposta de Melhoria do Bitcoin (BIP) intitulado “OP_CAT” que levou essa discussão a um novo nível.

Este rascunho, composto por apenas 13 linhas de código, carrega uma natureza funcional clara e intuitiva, definindo um novo código de operação tap que permite que dois valores sejam concatenados na pilha. Esta implementação de código foi claramente inspirada no OP_CAT original excluído.

As condições para a “ressurreição” foram cumpridas

Quanto ao motivo pelo qual um Código de Operação que foi excluído por Satoshi Nakamoto agora está sendo restaurado pelos desenvolvedores, a seção motivacional deste rascunho do BIP explica com alguns detalhes: isso é baseado principalmente em considerações de uso de memória, e OP_CAT faz com que o uso de memória de construções de script aumente exponencialmente a partir do tamanho do próprio script. Especificamente, um script simples que simplesmente envia um valor de 1 byte para a pilha, replica-o com OP_DUP Operation Code e o concatena 40 vezes com OP_CAT Operation Code pode fazer com que o valor da pilha aumente para um tamanho maciço de mais de 1 TB.

No entanto, com o avanço do tempo e o desenvolvimento da tecnologia, esta questão deixou de ser um obstáculo. Sob a arquitetura da TAP, há uma regra clara de que o tamanho máximo do elemento de pilha é estritamente limitado a 520 bytes. Esta alteração resolve eficazmente os problemas de utilização da memória que podem ser causados pelo OP_CAT, proporcionando a possibilidade da sua “ressurreição” e integração.

Segue-se que OP_CAT está mais uma vez sendo trazido para discussão e considerado para reutilização, principalmente devido ao seu valor potencial na construção de scripts mais complexos e poderosos. Além disso, uma série de razões e mudanças preencheram as condições para a “ressurreição”, incluindo:

1. Demanda por contratos e protocolos inteligentes avançados: À medida que o ecossistema do Bitcoin cresceu, a demanda por contratos e protocolos inteligentes mais avançados e complexos aumentou. OP_CAT aumenta a expressividade e a funcionalidade das torneiras, permitindo que os objetos sejam combinados na pilha. Por exemplo, ele pode ser usado para construir e avaliar Merkle Tree e outras estruturas de dados hash, suportando assinaturas de árvore, assinaturas Lamport pós-quânticas, contratos de não repúdio, cofres e muito mais.

2. Outras histórias de sucesso on-chain: Alguns forks do Bitcoin, como o Bitcoin Cash e o Sidechain Liquid, reativaram o OP_CAT e o usaram para implementar a criação e o gerenciamento de tokens, canais de pagamento e maneiras de incorporar e recuperar dados no Blockchain. Isso indica que o OP_CAT pode ser usado com segurança e eficácia sob o ambiente apropriado e restrições.

3. Exploração da segurança quântica: Alguns estudos propuseram que, se operações como OP_CAT podem ser usadas, combinadas com tecnologias como assinaturas Lamport, transações e protocolos Bitcoin quantum-secure podem ser construídos. Esta exploração tem valor potencial para melhorar a segurança futura do sistema Bitcoin.

4. Comunidade e desenvolvimento tecnológico: O desenvolvimento contínuo da comunidade e tecnologia Bitcoin levou as pessoas a reconsiderar e avaliar decisões anteriores. À medida que uma compreensão mais profunda do protocolo Bitcoin e novas tecnologias surgem, recursos que antes eram considerados problemáticos ou inaplicáveis podem encontrar casos de uso seguros e úteis em novos contextos.

Garfo macio, fácil de falar

Em um nível técnico, poucas outras propostas de Bitcoin são tão fáceis de interpretar e entender quanto OP_CAT. Mas OP_CAT Operation Code será ativado redefinindo o Soft Fork do Operation Code OP_SUCCESS 126, o que obviamente não é uma tarefa fácil.

Lembre-se que o Soft Fork mais recente do Bitcoin ocorreu há três anos, quando o Taproot foi ativado, ajudando assim a abrir caminho para o nascimento dos Ordinais.

O consenso e a transparência são altamente valorizados pela comunidade Bitcoin, e quaisquer alterações significativas no código são amplamente discutidas e analisadas dentro da comunidade, incluindo soft forks. Para que um pedaço de código seja fundido na base de código do Bitcoin, ele precisa passar por um processo rigoroso e detalhado que garanta a qualidade da proposta e o consenso da comunidade. Aqui estão as principais etapas deste processo:

1. Escreva a proposta e o código: Primeiro, o desenvolvedor precisa escrever um documento detalhado da proposta. Este documento deve descrever claramente a motivação, os pormenores técnicos, a avaliação de impacto e quaisquer potenciais problemas ou desafios da proposta.

2. Discussão na comunidade: Uma vez que uma proposta de código é submetida à comunidade Bitcoin, ela é discutida e revisada pelos membros da comunidade (incluindo desenvolvedores, mineradores, investidores e usuários). Esta etapa é fundamental para garantir a viabilidade da proposta e recolher feedback.

3. Modificações e melhorias: Com base no feedback da comunidade, os autores do código podem precisar fazer modificações e melhorias na proposta.

4. Votar, chegar a um consenso: Algumas melhorias importantes (especialmente aquelas que envolvem o próprio protocolo Bitcoin) exigem um certo nível de consenso entre os membros da comunidade. Isso geralmente envolve o apoio da Miner, que precisa mostrar seu apoio à proposta, incluindo um sinal específico no Bloco que minera.

5. Implementação de código: Uma vez que um consenso é alcançado, o código será revisado pela equipe de desenvolvedores do Bitcoin Core. Esta etapa requer garantir a qualidade e a segurança do código.

6. Mesclar na base de código: Após a aprovação, o código será fundido na base de código oficial do Bitcoin.

7. Implantação e ativação: Finalmente, o novo código precisa ser implantado em seus sistemas por Mineradores e Operadores de Nós. Para alterações no nível do protocolo, geralmente há um limite de ativação que só entrará em vigor quando participantes suficientes da rede atualizarem para a nova versão.

Obviamente, a implementação do OP_ CAT Soft Fork ainda está em um estágio muito inicial, menos de quatro meses após o rascunho do BIP ter sido escrito, o número do BIP ainda não foi determinado, e ainda está na primeira fase de escrita da proposta e do código e na segunda fase de discussões da comunidade envolvendo desenvolvedores e usuários.

O que os desenvolvedores de Bitcoin estão dizendo

Vamos prestar especial atenção à discussão de OP_CAT entre os desenvolvedores de Bitcoin nos últimos anos.

Embora OP_CAT Operation Code tenha sido removido, a utilidade potencial de OP_CAT em facilitar contratos avançados e melhorar as linguagens de script Bitcoin tem sido repetidamente discutida entre os desenvolvedores. Por exemplo, sua capacidade de conectar valores de pilha é considerada uma barreira para o desenvolvimento de alguns protocolos Bitcoin, como o TumbleBit, cujo tamanho da transação pode ser muito reduzido se OP_CAT for suportado.

Agora que reunimos a newsletter da Optech e uma variedade de conteúdo relacionado, vamos resolver algumas das discussões dos desenvolvedores de Bitcoin sobre o OP_CAT Operation Code em ordem cronológica.

2019

Ethan Heilman, um dos patrocinadores do rascunho da OP_CAT Bitcoin Improvement Proposal (BIP), disse em um e-mail em outubro de 2019 que entendia por que ele foi removido por causa da situação terrível enfrentada pelos scripts na época, mas enfatizou o valor do OP_CAT como um Código de Operação: "A maioria dos protocolos que querem construir em cima do Bitcoin hoje têm uma limitação: os valores de pilha não podem ser conectados. Como pesquisador, se estou experimentando essa limitação, é provável que ela também esteja atrapalhando o progresso dos outros. Se eu pudesse acenar com minha varinha para reativar um dos códigos de operação desativados, escolheria OP_CAT. Claro, isso será acompanhado por uma condição: o tamanho de cada valor concatenado deve ser limitado a 64 bytes ou menos. 」

Quando se trata da discussão de OP_CAT, Andrew Poelstra é uma pessoa que nunca consegue se locomover. Ele escreveu um artigo intitulado “CAT and Schnorr Tricks I” em 30 de janeiro de 2021, o que causou uma onda de discussão sobre OP_CAT. Andrew Poelstra é o Diretor de Pesquisa da Blockstream e um veterano desenvolvedor de scripts BitcoinCryptography com uma forte presença na indústria.

No artigo, Andrew Poelstra explica: "OP_CAT ajuda a combinar dois elementos na pilha e empurrar o resultado mesclado de volta para a pilha. Esta função pode ser usada para montar vários elementos pequenos em um elemento grande, ou para decompor um elemento grande em vários elementos menores. CHECKSIGFROMSTACK (CSFS) é um Código de Operação nunca antes visto em Bitcoin que permite aos usuários realizar verificação de assinatura em dados arbitrários, ao contrário do Código de Operação CHECKSIG, que apenas verifica assinaturas de transações. 」

Além disso, ele ressalta que o uso de OP_CAT em conjunto com CHECKSIGFROMSTACK pode fornecer uma abordagem engenhosa para a introspeção transacional.

Nota: A introspeção da transação refere-se à capacidade de examinar e analisar os vários componentes de uma transação em si no Bitcoin Script. Simplificando, ele permite que o script “entenda” e processe os detalhes da transação que está processando, como verificar a saída da transação, o valor ou a assinatura específica. Desta forma, os scripts são capazes de responder de forma mais inteligente e matizada ao conteúdo específico da transação.

ISSO PERMITE QUE O USUÁRIO FORNEÇA OS DADOS PARA TODA A TRANSAÇÃO NA PILHA, E O SCRIPT USA OP_CAT PARA EMPACOTAR OS DADOS EM UM ÚNICO ITEM, HASH E, EM SEGUIDA, PASSÁ-LO PARA CHECKSIGFROMSTACK PARA VERIFICAR A ASSINATURA NOS DADOS. Em seguida, passa a mesma assinatura e chave secreta para CHECKSIG. Se ambas as verificações forem aprovadas, isso indica que os dados de transação fornecidos pelo usuário são realmente dados de transação reais. Dessa forma, o script pode usar diretamente esses dados para executar quaisquer verificações exigidas pelo contrato.

A influência de Andrew Poelstra, e a ideia do artigo, chamou a atenção dos desenvolvedores de Bitcoin, e na conferência daquela semana, houve muita discussão sobre essa combinação de Códigos de Operação e como fazer pequenas alterações na linguagem de script após a ativação do taproot poderia melhorar a flexibilidade do contrato.

Cerca de duas semanas após o lançamento de CAT e Schnorr Tricks I, Andrew Poelstra publicou um segundo artigo, CAT and Schnorr Tricks II, no qual Andrew Poelstra relata mais detalhes e seus pensamentos:

Em maio de 2019, o desenvolvedor do Bitcoin Jeremy Rubin propôs o Código de Operação CHECKOUTPUTSHASHVERIFY do Bitcoin, com o objetivo de implementar um Contrato Inteligente básico e limitado que evita os riscos técnicos e sociais de projetos anteriores de Contratos Inteligentes. Este Código de Operação foi posteriormente substituído por SECURETHEBAG e mais tarde por CHECKTEMPLATEVERIFY, que se tornou oficialmente Bitcoin Improvement Proposal BIP 0119 em janeiro de 2020.

Enquanto isso, Russell O’Connor sugere adicionar CHECKSIGFROMSTACK e OP_CAT Operation Code diretamente ao Bitcoin para suportar contratos inteligentes que não são restringidos pela proposta de Rubin. Embora a proposta tenha sido recebida com alguma oposição e a discussão acabou por diminuir, principalmente devido às ineficiências dos contratos inteligentes do tipo CAT+CHECKSIG e à impressão negativa a longo prazo de participações completas em contratos inteligentes universais.

Andrew Poelstra também estava relutante em apoiar o chamado recurso BitcoinSmart Contract no início. No entanto, no outono de 2019, uma troca privada com Ethan Heilman mudou de ideia. Ethan Heilman apontou que, apesar das preocupações, é realmente possível implementar contratos inteligentes que são considerados prejudiciais através do CHECKMULTISIG e não são realmente aceitos por carteiras e usuários devido à sua falta de reconhecimento e disponibilidade. Para o provar, Ethan Heilman desafiou as pessoas nas redes sociais a criarem contratos inteligentes “obscuros” viáveis, mas até agora ninguém conseguiu.

Assim, Andrew Poelstra passou a pensar que o medo de todos em relação aos contratos inteligentes poderia ser exagerado. O artigo também argumenta que o Smart Contract é inevitável no desenvolvimento do Bitcoin, mesmo que haja preocupações, e incentiva a exploração contínua da possibilidade de criar Smart Contract usando o Código de Operação OP_CAT não dedicado.

Em 2021

Isso foi seguido por um artigo de Jeremy Rubin em 6 de julho de 2021, explicando o OP_CAT da perspetiva da segurança quântica do Bitcoin. Jeremy Rubin não é apenas um desenvolvedor de Bitcoin, mas também o fundador da Judica, uma organização de P&D de Bitcoin focada no desenvolvimento da linguagem de programação Smart Contract do Bitcoin, Sapio.

Em e-mails e postagens de blog, Jeremy Rubin discute como verificar quantum-verificar Bitcoin com OP_CAT Código de Operação e assinaturas Lamport. O autor começa revisando uma postagem anterior no blog sobre como registrar valores de 5 bytes usando a aritmética do script Bitcoin e assinaturas Lamport. Embora este método seja puro, ele tem suas limitações. Jeremy Rubin teve uma ideia: e se pudéssemos assinar mensagens mais longas, especialmente se pudéssemos assinar até 20 bytes, poderíamos assinar um resumo HASH 160 potencialmente seguro para o quântico.

Jeremy Rubin explora ainda mais as implicações de assinar um resumo HASH 160 no artigo e explica a capacidade de revelar apenas a Chave Privada sem alterar o conteúdo assinado real, mesmo que o Quantum Computer quebre o ECDSA. Para fazer isso, os autores consultaram o cientista de criptografia Madars Virza e receberam uma resposta afirmativa.

Jeremy Rubin aponta que, se exigirmos que as assinaturas ECDSA sejam assinadas usando um algoritmo de assinatura de prova quântica, podemos ter prova quântica de Bitcoin. O esquema de assinatura de 5 bytes discutido anteriormente é, na verdade, uma assinatura Lamport quantum-safe. Infelizmente, este método requer pelo menos 20 bytes consecutivos.

Portanto, Jeremy Rubin propôs que algum tipo de operação OP_CAT-like era necessária. O artigo explica que OP_CAT não pode ser bifurcado suavemente diretamente para Segwit v 0 porque modifica a pilha. Assim, para simplificar, o autor mostra como usar um novo Operation Code OP_SUBSTRINGEQUALVERIFY que o Operation Code verifica se alguma parte de uma string é igual validando a semântica.

Em 5 de novembro de 2021, na Atlanta Bitcoin Conference, Jeremy Rubin e Andrew Poelstra estiveram entre os palestrantes discutindo a proposta de reativar o Código de Operação OP_CAT, argumentando que OP_CAT é importante no contexto do Bitcoin e destacando seu potencial, especialmente em termos de segurança quântica e tornando complexo o Smart Contract. Por exemplo, em combinação com o CAT e o Código de Operação de verificação de assinatura Schnorr, o Smart Contract não recursivo pode teoricamente ser implementado. Este contrato inteligente é capaz de colocar o hash SHA 2 de dados de transação diretamente na pilha. Ao fazê-lo, podem ser impostas, em certa medida, restrições a várias partes da transação.

A discussão também mencionou que, se o CAT for reintroduzido, pode tornar o Bitcoin complicado de algumas maneiras, ao mesmo tempo em que introduz novos recursos e possibilidades. Reiniciar o OP_CAT requer uma consideração cuidadosa para evitar problemas que ocorreram no passado, como explosões de memória.

2022

Em uma discussão na lista de discussão do desenvolvedor Bitcoin de 18 de maio de 2022 sobre a reintrodução do Código de Operação OP_CAT que foi removido do Bitcoin em 2010, o desenvolvedor ZmnSCPxj sugeriu que, para alcançar o inevitável Contrato Inteligente recursivo, OP_CAT precisaria ser combinado com o Código de Operação proposto, como OP_TX, OP_CHECKSIGFROMSTACK (CSFS), etc. O Contrato Inteligente Recursivo faz uso das regras do BitcoinConsensus para garantir que todo o Bitcoin recebido de um contrato só possa ser gasto no mesmo contrato.

Os contratos inteligentes recursivos dependem de técnicas de introspeção de transações, ou seja, um Código de Operação pode analisar uma parte da transação na qual o Código de Operação é executado. O Código de Operação existente fornece introspeção limitada. Para criar um Smart Contract recursivo, você precisa garantir que a saída anterior e a próxima sejam as mesmas. Portanto, a saída anterior, ou a próxima saída, ou ambas devem ser construídas dinamicamente a partir de seus elementos constituintes, e é por isso que CAT ou estruturas semelhantes são necessárias para implementar contratos inteligentes recursivos.

Nadav Ivgi destaca que o CAT ainda é necessário para resolver o problema de hashing ao criar contratos inteligentes recursivos, mas isso significa que recursos como CTV e APO, que se concentram na introspeção de saída, também podem ser combinados com CAT para criar contratos inteligentes recursivos. Ivgi argumenta que, quando usado em conjunto com a funcionalidade de taproot, validar a saída anterior com a próxima saída torna o script de contrato inteligente mais fácil de escrever e fornece links para dois exemplos de contrato inteligente recursivo.

ZmnSCPxj concordou com a análise de Ivgi e reiterou suas preocupações sobre os riscos de habilitar contratos inteligentes recursivos no Bitcoin, embora ele também tenha observado em um post de acompanhamento que os contratos inteligentes recursivos podem ser seguros porque não são realmente Turing Complete. Russell O’Connor cita o artigo de Andrew Poelstra descrevendo como o próprio CAT pode ser combinado com a funcionalidade existente do Bitcoin o suficiente para criar contratos inteligentes não recursivos e, teoricamente, se readicionado ao Bitcoin, também pode ser capaz de criar contratos inteligentes recursivos por conta própria.

Em 2023

Em janeiro, Anthony Towns lançou o Bitcoin Inquisition, uma réplica do Bitcoin Core projetada para rodar no sinete padrão para testar soft forks propostos e outras grandes mudanças de protocolo. A partir do final de 2023, a Inquisição Bitcoin apoiou uma série de propostas e, além disso, PRs (pull requests) projetados para OP_CAT, OP_VAULT e limitar transações de 64 bytes foram submetidos à sua base de código, o que deve expandir ainda mais as capacidades deste banco de testes.

Em 23 de agosto de 2023, na lista de discussão Lightning-Dev, Thomas Voegtlin teve a ideia de uma prova de fraude sobre o status de backups expirados. Voegtlin ressalta que é possível usar essa prova de fraude on-chain se OP_CHECKSIGFROMSTACK (CSFS) e OP_ CAT Operation Code forem adicionados ao Bitcoin de forma Soft Fork. A proposta suscitou muita discussão, com Peter Todd a salientar que o mecanismo básico é genérico e não se limita ao LN e pode ser útil em vários protocolos, mas também propôs um mecanismo mais simples que não será discutido aqui.

Em outubro, Rusty Russell estava trabalhando em um contrato inteligente de uso geral para a linguagem de script Bitcoin com mudanças mínimas. Ao mesmo tempo, muito importante, Ethan Heilman e Armin Sabouri publicaram conjuntamente um projeto de BIP propondo a adição do OP_CAT Operation Code, um Código de Operação para conectar dois elementos na pilha. Os debates sobre estes dois temas prosseguiram em novembro.

Em 2024

Estamos em janeiro de 2024, e a Quantum Cats realmente conseguiu levar a discussão sobre BIP e o processo Bitcoin para OP_CAT para o próximo nível.

Em uma interação com a comunidade, o desenvolvedor do Bitcoin Core, Ava Chow, disse: "Não acho que o CTV seja um consenso aproximado. Acho que outras propostas mais gerais de Smart Contract estão realmente mais próximas, como txhash ou CAT. No entanto, não acompanhei a discussão de perto. 」

Classificada pelo número de commits, Ava Chow (@achow 101) está atualmente classificada em 5º lugar no ranking de contribuidores de código Bitcoin Core com 1.292 commits de código e é uma das poucas a ter o direito de mesclar o código Bitcoin. Como resultado, ela também é muito influente na comunidade de desenvolvimento.

"Não estou a sugerir que ativemos o OP_CAT. Apoio o OP_CAT porque é o Código de Operação que tem mais probabilidades de chegar a um consenso. Se você não sabe sobre OP_CAT, eu resumo a situação nesta imagem. É o que diz Eric Wall (@ercwl), cocriador do Taproot Wizard.

No entanto, Ava Chow não parece ser absolutamente a favor da implementação do OP_CAT: "Como já disse, não acho que qualquer proposta de Smart Contract chegue perto ou tenha um consenso aproximado. Eu não acho que devemos tentar ativar qualquer um deles. 」

dez linhas de código para permitir que o Bitcoin implemente o Smart Contract

Como Eric Wall (@ercwl), cocriador do Taproot Wizard, explica, "As pessoas não percebem, mas OP_CAT é na verdade um dos blocos de construção do zkrollup no Bitcoin. 」

A reintrodução do OP_CAT fornece ao Bitcoin uma ferramenta poderosa para apoiar projetos como o BitVM, um conceito recentemente introduzido de validação de computação arbitrária no Bitcoin que será facilitado e mais eficiente graças ao OP_CAT. O ecossistema Bitcoin permite a criação de Smart Contracts mais versáteis e expressivos.

Leitura relacionada: O que os desenvolvedores veteranos acham do BitVM para calcular qualquer coisa no Bitcoin?

Com OP_CAT, os chamados contratos inteligentes podem ser implementados, ou seja, condições pré-especificadas são definidas para uma saída específica de Bitcoin. Isso não só abre a porta para novos métodos de escala, como o Blockstream’s Ark, mas também suporta muitas outras abordagens inovadoras que dependem de contratos inteligentes. Além disso, significa que o Bitcoin não é apenas uma rede de pagamento, mas também uma plataforma de computação versátil e escalável.

Embora o cocriador do Taproot Wizard, Eric Wall, esteja animado com o conceito por trás do BitVM, ele acredita que a proposta pode ser um “beco sem saída técnico” para o Bitcoin devido à sua enorme sobrecarga e longo ciclo de implementação. Ele teme que o BitVM possa distrair a comunidade e dificultar o desenvolvimento real. Apesar disso, a proposta da BitVM ainda mostra o espírito ativo de exploração e inovação no campo da tecnologia Blockchain e Smart Contract.

Na verdade, a própria equipe do projeto Taproot Wizard está trabalhando na implementação de uma solução de camada 2 no Bitcoin e, em um espaço anterior, eles também disseram que a rodada de financiamento concluída de US$ 7,5 milhões será usada para estudar as opções de escalonamento do Bitcoin.

Portanto, o soft fork do OP_CAT também será um passo importante para eles. Eric Wall, que costumava ser um membro do conselho da Fundação StarkNet, tem um grande interesse em construir DeFi em cima de criar uma camada de liquidação sem permissão, então quando o Ethereum começou a surgir em 2019, ele foi naturalmente atraído para o espaço de Finanças Descentralizadas no Ethereum.

A exploração do Bitcoin das Finanças Descentralizadas foi quase completamente abandonada quando se tornou evidente em 2019 que o Ethereum e outros blockchains poderiam escalar usando zk-rollups ou provas de fraude otimistas. Com pesquisas sobre a viabilidade do escalonamento zk-rollup aplicado ao Bitcoin, Wall se voltou para apoiar as Finanças Descentralizadas no Ethereum. Mas, eventualmente, ele está tentando trazer esse sistema e essas vantagens tecnológicas para o Bitcoin.

Além disso, em um tópico de discussão sobre OP_CAT no fórum bitcointalk, Carter Feldman (@cmpeq), fundador do projeto QED, foi questionado sobre como ele pretende alavancar esse Código de Operação em scripts Bitcoin, e se ele calcula os bytes médios da pilha de testemunhas e as taxas que podem ser incorridas.

Carter Feldman disse que reconhece que isso pode ser um pouco caro, mas explica que a prova de Merkel é usada principalmente em seu projeto para construir um script de bloqueio sem confiança ou sistema de peg como parte da camada dois zk no Bitcoin. Este sistema visa provar que uma certa quantidade de Bitcoin pode ser retirada para um endereço específico dada a raiz da árvore de retirada (como uma entrada pública para uma Prova de Conhecimento Zero).

Para fazer face aos custos, referiu que este seria um último recurso. Ele prevê que os usuários regulares podem comprar BTC embrulhado na segunda camada, fazendo com que o vendedor de BTC embrulhado bloqueie seu Token em L2 por um período de tempo, durante o qual o comprador deve provar que pagou ao vendedor em Bitcoin L1. Eles sabem que sempre podem trocar Bitcoin sem confiança, se quiserem. Ao mesmo tempo, vários grandes provedores de liquidez se tornariam entidades que realmente trocam entre wBTC e BTC e podem cobrar pequenas taxas para usuários menores que querem comprar wBTC deles ou fazer a ponte de volta para o Bitcoin.

Então, em geral, a proposta BIP do OP_CAT pode ajudar a construir contratos inteligentes no Bitcoin com apenas 13 linhas de código, mas ainda haverá muita discussão e soluções de teste para os detalhes específicos de cada projeto.

A cultura memética cria impulso e avança a tecnologia

Rijndael, membro da equipe TaprootWizards (@rot 13 maxi), usou as redes sociais para compartilhar as várias mecânicas complexas que eles usam para criar obras de arte. Para conseguir isso, eles contam com uma variedade de técnicas, incluindo recursão ordinal, transações pré-assinadas, criptografia simétrica e gerenciamento de carga do lado do cliente. No processo de criação da arte, eles optaram especificamente por usar transações pré-assinadas para executar operações, mostrando como pré-enviar o hash de uma transação usando um contrato inteligente, como OP_CAT ou CTV.

Mas Armin Sabouri comentou sarcasticamente: "O código e o esforço técnico necessários para criar uma coleção evolutiva de Tokens Não Fungíveis podem ser 100 vezes a quantidade de trabalho necessária para reativar um Código de Operação. 」

OP_CAT é considerado um Código de Operação simples e fácil de entender, e tem sido argumentado que pode tornar o Bitcoin “quântico seguro” assinando assinaturas ECDSA. Esta ideia foi apoiada por alguns e inspirou o Taproot Wizard a lançar a campanha Quantum Cats Non-fungible Token para aumentar a conscientização sobre OP_CAT.

No entanto, não é apenas OP_CAT que usa a cultura memética para criar impulso para o avanço tecnológico.

Inspirada pelo Quantum Cats e seu preço de venda de 0,1 BTC, e talvez parcialmente insatisfeita com seu alto preço de venda, a comunidade OP_CTV também lançou um meme sanduíche chamado #rubinsreubens para promover a tecnologia do OP_CTV.

Este meme sanduíche foi originalmente concebido como uma resposta bem-humorada ao gato quântico e seus memes. No entanto, é realmente muito eficaz porque, como CTV, adiciona hierarquia e você pode fazer quantas camadas no “sammich” quiser.

Este meme sanduíche tem atraído a atenção de muitas pessoas. Os memes são engraçados e podem ser usados para mostrar apoio a algo, mas também é importante entender o significado por trás disso. O objetivo do #rubinsreubens é melhorar a compreensão das propostas OP_ctv, LNHANCE e Soft Fork para o novo Código de Operação BTC e habilitar o Smart Contract.

Causas potenciais de falhas OP_CAT

Voltando ao OP_CAT, as pessoas podem se opor à introdução de recursos como OP_CAT por vários motivos. Primeiro, adicionar novos códigos de operação ou recursos como OP_CAT poderia aumentar a complexidade do Bitcoin, tornando-o mais difícil de entender e seguro de usar, aumentando o risco. Em segundo lugar, os problemas de segurança ao introduzir novos recursos não devem ser negligenciados, e os recursos que não foram totalmente testados podem abrigar vulnerabilidades que comprometem a segurança geral do Bitcoin. Além disso, se a atualização do soft fork não for adotada por todos os nós, pode fazer com que a rede se divida, fazendo com que diferentes versões da rede Bitcoin coexistam, tornando mais complicado chegar a um consenso.

Novos recursos podem representar problemas de compatibilidade, especialmente se não suportarem nós mais antigos, potencialmente excluindo alguns nós da rede, impactando negativamente o ecossistema do Bitcoin. Especialmente para aqueles usuários que não atualizaram, eles podem se ver incapazes de continuar participando da rede. Além disso, alguns podem ver a introdução de novos recursos como uma decisão precipitada sem priorizar a abordagem de questões urgentes no protocolo central do Bitcoin. Mudanças apressadas podem introduzir riscos e instabilidade desnecessários.

Além das considerações de segurança e risco, as duas maiores razões pelas quais o OP_CAT falhará são: o medo do Contrato Inteligente na comunidade Bitcoin e a falta de “legitimidade” no Contrato BitcoinSmart.

Medo de contratos inteligentes

O medo do contrato BitcoinSmart pode ser outro obstáculo significativo para alcançar OP_CAT. Como um componente central da tecnologia Blockchain, os contratos inteligentes desempenham um papel vital em muitos projetos de Blockchain, especialmente em plataformas como o Ethereum.

No entanto, na comunidade Bitcoin, a aceitação de contratos inteligentes é relativamente baixa, em parte devido a preocupações sobre os riscos e desafios que os contratos inteligentes podem representar. Os contratos inteligentes podem afetar os valores fundamentais do Bitcoin, como peer-to-peer, descentralização e segurança. A comunidade Bitcoin leva a manutenção desses valores fundamentais muito a sério, e quaisquer mudanças que sejam consideradas como ameaçando esses valores provavelmente serão contestadas.

Uma grande preocupação com os contratos inteligentes é que eles podem aumentar a complexidade e os riscos de segurança em toda a rede. Os contratos inteligentes geralmente envolvem lógica e código complexos, e qualquer pequeno bug ou vulnerabilidade pode levar a sérios problemas de segurança e até mesmo perda maciça de fundos, como aconteceu em alguns projetos de Blockchain no passado. Além disso, a introdução de contratos inteligentes pode tornar todo o sistema mais difícil de entender e auditar, aumentando a probabilidade de erros.

Além disso, a comunidade Bitcoin sempre colocou grande ênfase na manutenção da estabilidade e segurança da rede. A filosofia de design do Bitcoin inclina-se para a simplicidade e conservadorismo, priorizando a segurança e descentralização da rede. Consequentemente, quaisquer alterações significativas que possam constituir uma ameaça à ciberestabilidade estão sujeitas a um escrutínio intenso e a um debate alargado. A introdução de OP_CAT e Smart Contracts, embora potencialmente traga novos recursos e possibilidades para o Bitcoin, também pode ser vista como contrária à visão original e filosofia de design do Bitcoin.

Satoshi Nakamoto estava “errado”?

A restauração do OP_CAT Operation Code provocou uma discussão profunda na comunidade, em parte porque toca em um tópico sensível: isso significa que Satoshi Nakamoto está errado?

Como o fundador do Bitcoin, as decisões e o design original de Satoshi Nakamoto são tidos como bíblia por muitos, e sua visão original é considerada um guia central para o desenvolvimento do Bitcoin. Portanto, qualquer tipo de desafio ou modificação à decisão de Satoshi Nakamoto pode ser visto como desrespeitoso ao seu legado ou um desvio dos princípios fundamentais do Bitcoin. Afinal, na indústria de Blockchain, a legitimidade sempre foi um tópico inevitável.

Portanto, a proposta de restaurar o OP_CAT também toca em uma questão mais ampla: o Bitcoin deve ser uma entidade estática ou deve se adaptar ao ambiente tecnológico em mudança e às necessidades do usuário?

No entanto, o campo técnico está sempre progredindo e mudando, e o Bitcoin, como uma inovação tecnológica, não pode se livrar completamente dessa lei, e aparentemente a equipe do Taproot Wizard que apoia a restauração do OP_CAT pensa assim. Afinal, eles deliberadamente projetaram o maior BitcoinBlock de todos os tempos, logo abaixo do limite de 4 MB do Bitcoin, para lançar Assistentes Taproot de Token Não Fungível.

Udi Wertheimer, fundador da Taproot Wizard, disse que entende que muitas pessoas acreditam que o Bitcoin não deve mudar. Ele acredita que as mudanças no Bitcoin devem ser lentas, cautelosas e deliberadas. Ele argumenta que o Bitcoin é muito jovem para se solidificar totalmente, observando que o processo de governança está de alguma forma quebrado. Embora a comunidade técnica geralmente concorde que haverá mais atualizações para o Bitcoin, é realmente difícil determinar exatamente quais atualizações serão. Ainda assim, Wertheimer enfatizou que a mudança é necessária porque o Bitcoin atual ainda não é capaz de atender bilhões de pessoas.

É claro que essas mudanças também acarretam riscos e desafios, como questões de segurança, riscos de fragmentação da rede, problemas de compatibilidade, etc., que precisam ser cuidadosamente considerados e abordados.

Previsivelmente, no futuro, para garantir que as melhorias propostas sejam seguras e eficazes, implantar OP_CAT em um ambiente Testnet é uma etapa crítica que permite aos desenvolvedores identificar e resolver problemas sem afetar a Mainnet.

Ao mesmo tempo, a fim de realmente realizar o “reinício” do OP_CAT, todo o processo durará por um longo tempo, mesmo em anos, porque envolve muitas considerações e equilíbrios, incluindo detalhes técnicos, consenso da comunidade e considerações para a segurança e estabilidade da rede Bitcoin e, mais importante, amplo apoio e reconhecimento da comunidade.