O Santo Graal da rede de camada 2 do Bitcoin: Introspecção e convênios

Em comparação com os blockchains Turing-complete, como o Ethereum, a linguagem de script do Bitcoin é considerada significativamente limitada, capaz apenas de operações básicas e até mesmo sem funções de multiplicação e divisão. Mais importante ainda, os próprios dados do blockchain são quase inacessíveis aos scripts, o que leva a graves limitações de flexibilidade e programabilidade. Consequentemente, há muito tempo as pessoas buscam maneiras de habilitar a introspecção para scripts de Bitcoin.

Introspecção refere-se à capacidade de Bitcoin para inspecionar e restringir dados de transações. Isso permite que os scripts controlem o uso de fundos com base em detalhes específicos da transação, possibilitando funcionalidades mais complexas. Atualmente, a maioria dos opcodes do Bitcoin empurra dados fornecidos pelo usuário para a pilha ou manipula dados já existentes na pilha. Os opcodes de introspecção, no entanto, podem enviar dados de transações atuais (como registros de data e hora, valores e IDs de transações) para a pilha, permitindo um controle mais granular sobre os gastos com UTXO.

Atualmente, há apenas três opcodes principais nos scripts do Bitcoin que oferecem suporte à introspecção: CHECKLOCKTIMEVERIFY, CHECKSEQUENCEVERIFY e CHECKSIG. CHECKSIG tem diversas variantes, incluindo CHECKSIGVERIFY, CHECKSIGADD, CHECKMULTISIG e CHECKMULTISIGVERIFY.

Convênios são restrições sobre como os tokens podem ser transferidos. Os usuários podem especificar como os UTXOs são distribuídos por meio de convênios, muitos dos quais são implementados usando opcodes de introspecção. Atualmente, a Bitcoin Optech categoriza a introspecção em entradas de convênio.

Atualmente, o Bitcoin tem dois convênios: CSV (CheckSequenceVerify) e CLTV (CheckLockTimeVerify), ambos baseados no tempo e que formam a base de muitas soluções de escalonamento, como a Lightning Network. Isso indica que as soluções de escalonamento do Bitcoin dependem muito da introspecção e dos convênios.

Como adicionar condições às transferências de tokens

No mundo criptográfico, o método mais comum é o compromissos, geralmente implementado com hashes. Para provar que as condições de transferência foram atendidas, são usados mecanismos de assinatura para verificação. Portanto, os convênios envolvem vários ajustes em hashes e assinaturas.

As propostas de opcode de convênio amplamente discutidas são as seguintes:

CTV (CheckTemplateVerify) BIP-119

O CTV (CheckTemplateVerify), incluído no BIP-119, é uma atualização do Bitcoin altamente debatida. O CTV permite que os scripts de saída especifiquem modelos para transações de gastos, incluindo campos como nVersion, nLockTime, scriptSig hash, contagem de entrada, hash de sequências, contagem de saída, hash de saídas e índice de entrada. Essas restrições de modelo são implementadas por meio de um compromisso de hash, e os scripts de gastos futuros verificarão se os valores de hash dos campos especificados na transação de gastos correspondem aos do script de entrada. Esses modelos definem essencialmente a hora, o método e o valor das futuras transações UTXO.

Notavelmente, o TXID de entrada é excluído do compromisso de hash. Essa exclusão é necessária porque, seja em transações Legacy ou Segwit, o TXID depende do valor scriptPubKey ao usar o tipo de assinatura padrão SIGHASH_ALL. A inclusão do TXID criaria uma dependência circular, tornando impossível a construção do compromisso de hash.

O CTV realiza a introspecção obtendo diretamente as informações de transação especificadas por meio de um novo código de operação, fazendo o hash e comparando-as com o compromisso na pilha. Esse método consome menos espaço na cadeia, mas carece de alguma flexibilidade.

A base das soluções de segunda camada, como a Lightning Network, são as transações pré-assinadas. A pré-assinatura geralmente significa gerar e assinar transações com antecedência, mas não transmiti-las até que determinadas condições sejam atendidas. Essencialmente, o CTV implementa uma função de pré-assinatura mais rigorosa, publicando o compromisso pré-assinado diretamente na cadeia, permitindo transações somente de acordo com o modelo predefinido.

O CTV foi inicialmente proposto para aliviar o congestionamento do Bitcoin e também pode ser chamado de controle de congestionamento. Durante os períodos de alto congestionamento, o CTV pode confirmar várias transações futuras por meio de uma única transação, evitando a necessidade de transmitir várias transações durante o congestionamento e concluir as transações reais depois que o congestionamento diminuir. Isso pode ajudar significativamente durante as execuções de troca. Além disso, os modelos podem ser usados para implementar cofres, impedindo ataques de hackers, pois o destino dos fundos é predeterminado, impossibilitando que os hackers enviem UTXOs usando o script do CTV para seus endereços.

O CTV pode melhorar significativamente as redes de segunda camada. Por exemplo, na Lightning Network, a implementação de Timeout Trees e Channel Factories usando CTV permite que um único UTXO se expanda em uma árvore CTV, abrindo vários canais de estado com apenas uma transação e confirmação na cadeia. Além disso, o CTV oferece suporte a transações atômicas (ATLC) no protocolo Ark.

APO (SIGHASH_ANYPREVOUT) BIP-118

O BIP-118 propõe um novo sinalizador de hash de assinatura para o tapscript, chamado SIGHASH_ANYPREVOUT, para facilitar a escrita de uma lógica de gastos mais flexível. O APO e o CTV são semelhantes em muitos aspectos. Para resolver a dependência circular entre scriptPubKeys e TXIDs, a solução do APO é excluir as informações de entrada relevantes e assinar apenas a saída, permitindo que as transações se vinculem dinamicamente a diferentes UTXOs.

Logicamente, a operação de verificação OP_CHECKSIG (e seus opcodes relacionados) tem três funções:

1. Reúna partes da transação de gastos.
2. Faça um hash nessas partes.
3. Verifica se o hash é assinado pela chave fornecida.

O conteúdo específico da assinatura pode ser ajustado de forma significativa, e os campos da transação que são assinados são determinados pelo sinalizador SIGHASH. De acordo com a definição dos opcodes de assinatura BIP 342, os sinalizadores SIGHASH incluem SIGHASH_ALL, SIGHASH_NONE, SIGHASH_SINGLE e SIGHASH_ANYONECANPAY, entre outros. SIGHASH_ANYONECANPAY controla a entrada, enquanto os outros controlam a saída.

SIGHASH_ALL é o sinalizador padrão do SIGHASH, assinando todas as saídas. SIGHASH_NONE não assina nenhuma saída e SIGHASH_SINGLE assina apenas uma saída especificada. SIGHASH_ANYONECANPAY pode ser definido com os outros três sinalizadores e, se definido, assina somente a entrada especificada; caso contrário, todas as entradas devem ser assinadas.

Nenhum desses sinalizadores SIGHASH pode eliminar o impacto das entradas. Até mesmo o SIGHASH_ANYONECANPAY exige um compromisso com uma entrada.

Portanto, o BIP 118 introduz o SIGHASH_ANYPREVOUT. As assinaturas APO não precisam se comprometer com o UTXO de entrada gasto (chamado PREVOUT), assinando apenas a saída, o que proporciona maior flexibilidade no controle do Bitcoin. Ao pré-construir transações e criar assinaturas e chaves públicas de uso único correspondentes, os ativos enviados para esse endereço de chave pública devem ser gastos por meio da transação pré-construída, alcançando o convênio.

A flexibilidade do APO também pode ser usada para reparar transações. Se uma transação ficar presa na cadeia devido a taxas baixas, outra transação pode ser facilmente criada para aumentar a taxa sem a necessidade de novas assinaturas. Além disso, para carteiras com várias assinaturas, as assinaturas que não dependem da entrada gasta tornam as operações mais simples.

Ao eliminar a dependência circular entre scriptPubKeys e TXIDs de entrada, o APO pode obter introspecção adicionando dados de saída na testemunha, embora isso ainda exija espaço adicional de dados de testemunha.

Para protocolos fora da cadeia, como o Lightning Network e os cofres, o APO reduz a necessidade de armazenamento de estado intermediário, diminuindo significativamente os requisitos de armazenamento e a complexidade. O caso de uso mais direto do APO é o Eltoo, simplificando as fábricas de canais, construindo torres de vigilância leves e baratas e permitindo saídas unilaterais sem deixar estados errôneos, melhorando o desempenho da Lightning Network. O APO pode simular a funcionalidade do CTV, embora exija armazenamento pessoal de assinaturas e transações pré-assinadas, o que o torna mais caro e menos eficiente que o CTV.

A principal crítica do APO é a necessidade de uma nova versão de chave, o que o torna incompatível com os sistemas existentes. Além disso, o novo tipo de hash de assinatura pode introduzir possíveis riscos de gasto duplo. Após extensas discussões na comunidade, o APO agora exige uma assinatura comum além da original, aliviando as preocupações com a segurança e ganhando seu número BIP-118.

OP_VAULT BIP-345

O BIP-345 propõe dois novos opcodes, OP_VAULT e OP_VAULT_RECOVER, para trabalhar com o CTV e implementar um convênio dedicado que impõe um período de atraso no gasto de tokens especificados, durante o qual o gasto pode ser “revogado” por meio de um caminho de recuperação.

Os usuários podem criar um cofre configurando um endereço Taproot específico, incluindo pelo menos dois scripts no MAST: um script OP_VAULT para facilitar o processo de retirada esperado e um script OP_VAULT_RECOVER para garantir a recuperação das moedas antes da conclusão da retirada.

Como a OP_VAULT consegue realizar retiradas com bloqueio de tempo ininterrupto?

Em termos simples, o opcode OP_VAULT substitui o script OP_VAULT gasto por um script especificado, atualizando um único nó folha no MAST e mantendo o restante inalterado. Isso é semelhante ao TLUV, mas sem suporte a atualizações de chaves internas.

A introdução de um modelo durante as atualizações de script pode restringir os efeitos de pagamento. O parâmetro de bloqueio de tempo é especificado por OP_VAULT, enquanto o modelo trazido pelo opcode CTV restringe o conjunto de saídas gastas por esse caminho de script.

O BIP-345 foi projetado para cofres, permitindo que os usuários tenham um caminho de recuperação altamente seguro (paper wallet, multiassinatura distribuída) enquanto configuram um atraso de gastos para pagamentos de rotina. O dispositivo do usuário monitora continuamente os gastos do cofre, permitindo a recuperação se ocorrer uma transferência não autorizada.

A implementação de cofres com o BIP-345 requer a consideração de questões de taxas, especialmente para transações de recuperação. As possíveis soluções incluem CPFP (Child Pays for Parent), âncoras temporárias e novos sinalizadores de hash de assinatura, como SIGHASH_GROUP.

TLUV (TapleafUpdateVerify)

O esquema TLUV foi criado em torno do Taproot e tem como objetivo resolver o problema da saída eficiente de UTXOs compartilhados. O princípio orientador é que, quando uma saída do Taproot é gasta, podemos usar a estrutura interna do endereço do Taproot e as transformações criptográficas para atualizar parcialmente a chave interna e o MAST de acordo com as etapas de atualização descritas pelo script TLUV, obtendo assim a funcionalidade do contrato.

A ideia do esquema TLUV é criar um novo endereço Taproot com base na entrada de gastos atual por meio de um novo opcode TAPLEAF_UPDATE_VERIFY, que pode executar uma ou mais das seguintes operações:

• Atualizar a chave pública interna
• Aparar o caminho de Merkle
• Remover o nó folha atualmente em execução
• Adicionar um novo nó folha ao final do caminho de Merkle

Especificamente, o TLUV recebe três entradas:

1. Uma especificação sobre como atualizar a chave pública interna
2. Um novo nó folha para o caminho de Merkle
3. Uma especificação sobre se o nó folha atual deve ser removido e/ou quantos nós folha do caminho de Merkle devem ser removidos

O opcode da TLUV calcula o scriptPubKey atualizado e verifica se a saída correspondente à entrada atual é gasta com esse scriptPubKey.

A inspiração para o TLUV são os pools de moedas. Atualmente, os pools conjuntos podem ser criados usando transações pré-assinadas, mas se você quiser obter saídas sem permissão, precisará criar um número exponencialmente crescente de assinaturas. A TLUV permite saídas sem permissão sem nenhuma transação pré-assinada. Por exemplo, um grupo de parceiros usa o Taproot para criar um UTXO compartilhado, reunindo seus fundos. Eles podem movimentar fundos internamente usando a chave Taproot ou assinar em conjunto para fazer pagamentos externos. Os indivíduos podem sair do pool compartilhado a qualquer momento, removendo seu caminho de pagamento, enquanto outros podem continuar a concluir os pagamentos pelo caminho original sem expor informações adicionais sobre os membros restantes. Esse método é mais eficiente e privado em comparação com transações não compartilhadas.

O código de operação TLUV consegue restrições parciais de gastos atualizando o MAST original. No entanto, ele não consegue introspecção dos valores de saída. Portanto, é necessário um novo opcode IN_OUT_AMOUNT, que coloca dois dados na pilha: o valor do UTXO dessa entrada e o valor da saída correspondente. Espera-se que a pessoa que estiver usando o TLUV use operadores matemáticos para verificar se os fundos estão preservados corretamente no scriptPubKey atualizado.

A introspecção dos valores de saída acrescenta outra complexidade porque os valores de Bitcoin são representados em satoshis e exigem até 51 bits, mas os scripts só permitem operações matemáticas de 32 bits. Isso requer a atualização dos operadores no script, redefinindo o comportamento do opcode ou usando SIGHASH_GROUP para substituir IN_OUT_AMOUNT.

Espera-se que a TLUV forneça soluções para pools de moedas descentralizados da Camada 2, embora a confiabilidade em termos de ajuste das chaves públicas da Taproot precise de mais confirmação.

MATT

O MATT (Merkleize All The Things) visa atingir três objetivos: Merkleizing state, Merkleizing scripts e Merkleizing execution, obtendo assim contratos inteligentes gerais.

• Estado de Merkleizing: Construa uma Merkle Trie em que cada nó folha seja um hash do estado e a Merkle Root represente todo o estado do contrato.
• Scripts de Merkleizing: Um MAST construído com Tapscript em que cada nó folha é um possível caminho de transição de estado.
• Execução de Merkleizing: obtido por meio de compromissos criptográficos e mecanismos de contestação de fraude. Para qualquer função computacional, os participantes podem computar fora da cadeia e publicar compromissos, f(x)=y. Se outros participantes encontrarem o resultado f(x)=z, eles poderão contestá-lo, e a arbitragem será realizada por meio de uma pesquisa binária, semelhante ao princípio do Rollup otimista.

Para alcançar o MATT, os scripts de programação de Bitcoin precisam ter as seguintes funcionalidades:

1. Aplicar um script específico em uma saída (e suas quantidades)
2. Anexar dados a uma saída
3. Ler dados da entrada atual (ou de outras entradas)

O segundo ponto é crucial, pois os dados dinâmicos permitem a computação do estado por meio de dados de entrada fornecidos pelo gastador, simulando uma máquina de estado e decidindo o próximo estado e os dados anexados. O MATT propõe o opcode OP_CHECKCONTRACTVERIFY (OP_CCV), uma combinação dos opcodes OP_CHECKOUTPUTCONTRACTVERIFY e OP_CHECKINPUTCONTRACTVERIFY propostos anteriormente, com um parâmetro de sinalizadores adicional para especificar o destino da operação.

Controle de quantidades de saída: A maneira mais direta é por meio da introspecção direta. Entretanto, os valores de saída são números de 64 bits que exigem operações de 64 bits, o que aumenta a complexidade da implementação do script do Bitcoin. O CCV adota uma verificação atrasada semelhante à OP_VAULT, somando os valores de entrada de todas as entradas para a mesma saída com CCV como o limite inferior desse valor de saída. A verificação é adiada para o processo de transação em vez de durante a avaliação do script de entrada.

Dada a generalidade das provas de fraude, algumas variantes dos contratos MATT devem alcançar todos os tipos de contratos inteligentes ou construções de Camada 2, embora requisitos adicionais (como lock-in de capital e atrasos no período de desafio) precisem de uma avaliação precisa. São necessárias mais pesquisas para avaliar quais aplicativos são transações aceitáveis. Por exemplo, usando compromissos criptográficos e mecanismos de desafio de fraude para simular funções OP_ZK_VERIFY, obtendo Rollups sem confiança no Bitcoin.

Na prática, as coisas já estão acontecendo. Johan Torås Halseth implementou o elftrace usando o opcode OP_CHECKCONTRACTVERIFY da proposta de soft fork MATT, permitindo que todos os programas suportados pela compilação RISC-V sejam verificados na cadeia do Bitcoin, possibilitando pontes de verificação nativas do Bitcoin para protocolos de contrato.

CSFS (OP_CHECKSIGFROMSTACK)

A partir da introdução do opcode APO, sabemos que OP_CHECKSIG (e operações relacionadas) é responsável pela montagem de transações, hashing e verificação de assinatura. Entretanto, a mensagem que ele verifica é derivada da serialização da transação usando esse opcode, não permitindo a especificação de outras mensagens. Em termos simples, OP_CHECKSIG (e operações relacionadas) serve para verificar se o UTXO como entrada de transação está autorizado a ser gasto pelo detentor da assinatura, protegendo assim a segurança do Bitcoin.

O CSFS, como o próprio nome sugere, verifica as assinaturas da pilha. O código de operação CSFS recebe três parâmetros da pilha: uma assinatura, uma mensagem e uma chave pública, e verifica a validade da assinatura. Isso significa que qualquer mensagem pode ser passada para a pilha por meio de dados de testemunha e verificada pelo CSFS, possibilitando algumas inovações no Bitcoin.

A flexibilidade do CSFS permite que ele implemente vários mecanismos, como assinaturas de pagamento, delegação de autoridade, contratos oracle e títulos de proteção contra gastos duplos e, mais importante, introspecção de transações. O princípio da introspecção de transações usando o CSFS é muito simples. Se o conteúdo da transação usado pelo OP_CHECKSIG for colocado na pilha por meio da testemunha e a mesma chave pública e assinatura forem usadas para verificar com o CSFS e o OP_CHECKSIG, se ambos forem aprovados, então o conteúdo de qualquer mensagem passada para o CSFS é o mesmo da transação de gastos serializada (e outros dados) implicitamente usada pelo OP_CHECKSIG. Em seguida, obtemos dados de transação verificados na pilha, que podem ser usados para aplicar restrições à transação de gastos com outros opcodes.

O CSFS geralmente aparece com o OP_CAT porque o OP_CAT pode concatenar diferentes campos da transação para concluir a serialização, permitindo uma seleção mais precisa dos campos da transação para introspecção. Sem o OP_CAT, o script não pode recomputar hashes a partir de dados verificáveis individualmente, portanto, ele só pode verificar se um hash corresponde a um valor específico, o que significa que as moedas só podem ser gastas por meio de uma única transação específica.

O CSFS pode obter opcodes como CLTV, CSV, CTV, APO e é um opcode de introspecção geral, o que também ajuda nas soluções de escalonamento da camada 2 para o Bitcoin. Sua desvantagem é que ele exige a adição de uma cópia completa da transação assinada à pilha, o que pode aumentar significativamente o tamanho das transações que desejam usar o CSFS para introspecção. Por outro lado, os opcodes de introspecção de finalidade única, como CLTV e CSV, têm a menor sobrecarga, mas a adição de cada novo opcode de introspecção especial exige alterações de consenso.

TXHASH (OP_TXHASH)

OP_TXHASH é um opcode de introspecção muito simples que permite que o operador selecione o hash de um campo e o coloque na pilha. Especificamente, OP_TXHASH retira um sinalizador txhash da pilha, calcula um txhash (sinalizado) com base no sinalizador e coloca o hash resultante na pilha.

Devido à semelhança entre o TXHASH e o CTV, houve uma ampla discussão na comunidade sobre os dois.

O TXHASH pode ser visto como uma atualização geral do CTV, fornecendo um modelo de transação mais avançado que permite aos usuários especificar partes da transação de gastos, resolvendo muitos problemas relacionados a taxas de transação. Diferentemente de outros opcodes de contrato, o TXHASH não exige o fornecimento de uma cópia dos dados necessários na testemunha, reduzindo ainda mais as necessidades de armazenamento. Ao contrário do CTV, o TXHASH não é compatível com NOP e só pode ser implementado em tapscript. A combinação de TXHASH e CSFS pode ser considerada uma alternativa ao CTV e ao APO.

Em termos de construção de contratos, o TXHASH é mais fácil de obter “contratos aditivos”, colocando todas as partes dos dados da transação que você deseja fixar na pilha, fazendo o hash entre elas e verificando se o resultado corresponde a um valor fixo. O CTV é mais fácil de obter “contratos subtrativos”, colocando na pilha todas as partes dos dados da transação que você deseja manter livres. Em seguida, usando o OP_SHA256 contínuo, a partir de um estado intermediário fixo, esse estado intermediário confirma o prefixo dos dados de hash da transação. As partes livres são transformadas em hash nesse estado intermediário.

Espera-se que o campo TxFieldSelector definido na especificação TXHASH seja expandido para outros códigos operacionais, como OP_TX.

O BIP relacionado ao TXHASH está atualmente em status de rascunho no Github e ainda não recebeu um número.

OP_CAT

OP_CAT é um opcode um tanto misterioso que foi preterido por Satoshi Nakamoto devido a preocupações com a segurança. No entanto, recentemente ele provocou uma ampla discussão entre os desenvolvedores do núcleo do Bitcoin, tornando-se até mesmo um meme na comunidade on-line. Por fim, o OP_CAT foi aprovado como BIP-347, e muitos o consideram a proposta de BIP mais provável de ser aprovada em um futuro próximo.

Na realidade, o comportamento do OP_CAT é muito simples: ele concatena dois elementos da pilha em um só. Mas como isso habilita a funcionalidade do contrato?

A função de concatenar dois elementos corresponde a uma poderosa estrutura de dados criptográficos conhecida como Merkle Trie. A construção de uma Merkle Trie requer apenas operações de concatenação e hashing, ambas disponíveis nos scripts do Bitcoin. Portanto, com o OP_CAT, podemos teoricamente verificar Merkle Proofs em scripts do Bitcoin, que é o método de verificação leve mais comum em blockchains.

Conforme mencionado anteriormente, o CSFS pode usar o OP_CAT para obter um esquema geral de contrato. De fato, mesmo sem o CSFS, a estrutura das assinaturas Schnorr permite que o próprio OP_CAT obtenha a introspecção da transação.

Em uma assinatura Schnorr, a mensagem a ser assinada é composta pelos seguintes campos:

• Versão
• Tempo de bloqueio
• Contagem de entrada
• Contagem de saída
• Lista de entradas (cada uma incluindo hash de transação anterior, índice, comprimento do script, script, sequência)
• Lista de saídas (cada uma incluindo valor, comprimento do script, script)

Esses campos contêm os principais elementos de uma transação. Colocando-os em scriptPubKey ou witness e usando OP_CAT e OP_SHA256, podemos construir uma assinatura Schnorr e verificá-la com OP_CHECKSIG. Se a verificação for aprovada, a pilha manterá os dados da transação verificada, permitindo a introspecção da transação. Isso nos permite extrair e “inspecionar” várias partes da transação, como suas entradas, saídas, endereços de destino ou valores de Bitcoin envolvidos.

Para obter princípios criptográficos mais detalhados, consulte o artigo de Andrew Poelstra “CAT and Schnorr Tricks”.

Em resumo, a flexibilidade do OP_CAT o torna capaz de imitar praticamente qualquer opcode de contrato, e muitos opcodes de contrato dependem de sua funcionalidade. Isso aumenta significativamente sua posição na lista de mesclagem. Teoricamente, apenas com o OP_CAT e os opcodes de Bitcoin existentes, poderíamos construir um BTC ZK Rollup com minimização de confiança. A Starknet, a Chakra e outros parceiros do ecossistema estão trabalhando ativamente para que isso aconteça.

Conclusão

À medida que exploramos várias estratégias para expandir o Bitcoin e aumentar sua capacidade de programação, fica evidente que o caminho a seguir envolve uma combinação de melhorias nativas, computação fora da cadeia e funcionalidades complexas de script.

Sem uma camada de base flexível, é impossível construir uma segunda camada mais flexível.

A escalabilidade da computação fora da cadeia é o futuro, mas a capacidade de programação do Bitcoin precisa ser superada para suportar melhor a escalabilidade e se tornar uma verdadeira moeda mundial.

No entanto, a computação do Bitcoin é fundamentalmente diferente da computação da Ethereum. O Bitcoin suporta apenas a “verificação” como uma forma de computação, enquanto a Ethereum é fundamentalmente computacional, com a verificação como um subproduto. Essa diferença é evidente no fato de que a Ethereum cobra taxas de gás por transações fracassadas, enquanto a Bitcoin não cobra.

Os contratos são uma forma de contratos inteligentes baseados em verificação em vez de computação. Com relação aos contratos, com exceção de alguns fundamentalistas rígidos de Satoshi, a maioria das pessoas acredita que os contratos são uma boa opção para aprimorar o Bitcoin. Entretanto, a comunidade está constantemente debatendo qual esquema usar para implementar contratos.

APO, OP_VAULT e TLUV se inclinam para aplicativos diretos. Ao escolhê-los, é possível implementar aplicativos específicos de forma mais econômica e eficiente. Os entusiastas da Lightning Network preferem o APO porque ele atinge a simetria LN; se você quiser criar um cofre, é melhor usar o OP_VAULT; para criar um CoinPool, o TLUV é mais privado e eficiente. OP_CAT e TXHASH são mais gerais, com menos vulnerabilidades de segurança, e podem alcançar mais casos de uso por meio de combinações com outros opcodes, embora potencialmente ao custo da complexidade do script. O CTV e o CSFS ajustaram a abordagem de processamento de blockchain: O CTV implementa saídas atrasadas e o CSFS implementa assinaturas atrasadas. O MATT é relativamente único, usando execução otimista e provas de fraude, e conta com a estrutura Merkle Trie para obter contratos inteligentes gerais, embora ainda exija novos opcodes para fornecer recursos de introspecção.

Vemos que a comunidade Bitcoin já está discutindo intensamente a possibilidade de introduzir contratos por meio de um soft fork. A Starknet anunciou oficialmente sua entrada no ecossistema do Bitcoin, planejando implementar a liquidação na rede Bitcoin dentro de seis meses após a fusão do OP_CAT. A Chakra continuará a monitorar os últimos desenvolvimentos no ecossistema Bitcoin, promoverá a fusão do soft fork OP_CAT e usará a programabilidade trazida pela introspecção e pelos contratos para criar uma camada de liquidação Bitcoin mais segura e eficiente.