visão geral

em comparação com blockchains com capacidade de turing como ethereum, a programação de bitcoin é considerada altamente restritiva, capaz apenas de operações básicas e até mesmo sem suporte para multiplicação e divisão. mais importante, os próprios dados do blockchain são quase inacessíveis para scripts, resultando em uma falta significativa de flexibilidade e programabilidade. portanto, tem havido um esforço de longa data para permitir que scripts de bitcoin alcancem introspecção.

introspecção refere-se à capacidade de scripts bitcoin de inspecionar e restringir dados de transação. 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 existentes na pilha. no entanto, os opcodes de introspecção podem empurrar dados da transação atual (como carimbos de data/hora, quantidades, txid, etc.) para a pilha, permitindo um controle mais detalhado sobre os gastos de utxo.

até o momento, apenas três opcodes principais no script do bitcoin oferecem suporte à introspecção: checklocktimeverify, checksequenceverify e checksig, juntamente com suas variantes checksigverify, checksigadd, checkmultisig e checkmultisigverify.

convênio, simplificando, refere-se a restrições sobre como as moedas são transferidas, permitindo que os usuários especifiquem como os UTXOs são distribuídos. muitos convênios são implementados por meio de opcodes de introspecção, e as discussões sobre introspecção agora foram categorizadas sob o tópico de convênios em Bitcoin optech.

bitcoin atualmente tem dois pactos, csv (verificação de sequência de cheque) e cltv (verificação de tempo de bloqueio), ambos pactos baseados em tempo que são fundamentais para muitas soluções de escalonamento como a rede lightning. isso ilustra como as soluções de escalonamento do bitcoin dependem muito da introspecção e dos pactos.

como adicionamos condições para a transferência de moedas? na criptosfera, nosso método mais comum é através de compromissos, frequentemente implementados por meio de hashes. para provar que os requisitos de transferência são atendidos, mecanismos de assinatura também são necessários para verificação. assim, muitos ajustes em hashes e assinaturas existem dentro de convênios.

abaixo, descreveremos a amplamente discutida proposta de opcode de convênio.

ctv (checktemplateverify) bip-119

ctv (checktemplateverify) é uma proposta de atualização do Bitcoin contida no bip-119 que tem recebido significativa atenção da comunidade. ctv permite que o script de saída especifique um modelo para gastar os fundos em uma transação, incluindo campos como nversion, nlocktime, scriptsig hash, input count, sequences hash, output count, outputs hash, input index. Essas restrições de modelo são implementadas por meio de um compromisso de hash, e quando os fundos são gastos, o script verifica se os valores de hash dos campos especificados na transação de gasto correspondem aos valores de hash no script de entrada. Isso efetivamente limita o tempo, método e valor de transações futuras desse utxo.

notavelmente, o input txid é excluído deste hash. esta exclusão é necessária, pois em transações legacy e segwit, o txid depende dos valores no scriptpubkey ao usar o tipo de assinatura sighash_all padrão. incluir o txid levaria a uma dependência circular no compromisso de hash, tornando impossível construir.

ctv implementa a introspecção ao puxar diretamente as informações de transação especificadas para hash e compará-las com o compromisso na pilha. Este método de introspecção é menos exigente no espaço da cadeia, mas carece de alguma flexibilidade.

A base das soluções de segunda camada do Bitcoin, como a Lightning Network, são transações pré-assinadas. Pré-assinatura geralmente se refere à geração e assinatura antecipada de transações, mas sem transmiti-las até que certas condições sejam atendidas. Essencialmente, o CTV implementa uma forma mais rigorosa de pré-assinatura, publicando o compromisso da pré-assinatura na cadeia, restrito ao modelo predefinido.

ctv foi inicialmente proposto para aliviar a congestão no Bitcoin, que também pode ser referida como controle de congestionamento. Durante períodos de alta congestão, ctv pode se comprometer com múltiplas transações futuras dentro de uma única transação, evitando a necessidade de transmitir várias transações durante os horários de pico e completando as transações reais uma vez que a congestão diminui. Isso poderia ser particularmente útil durante as corridas bancárias de troca. Além disso, o modelo também pode ser usado para implementar cofres para proteção contra ataques de hackers. Como a direção dos fundos é predeterminada, os hackers não podem direcionar os UTXOs usando scripts de ctv para seus próprios endereços.

ctv pode aumentar significativamente as redes de camada dois. por exemplo, na rede lightning, ctv pode permitir a criação de árvores de tempo limite e fábricas de canais, expandindo um único utxo em uma árvore ctv, abrindo vários canais de estado com apenas uma transação e uma confirmação. Além disso, ctv também suporta negociações atômicas no protocolo ark através de atlc.

apo (sighash_anyprevout) bip-118

bip-118 introduz um novo tipo de sinalizador de hash de assinatura para tapscript, com o objetivo de facilitar uma lógica de gasto mais flexível conhecida como sighash_anyprevout. apo e ctv têm muitas semelhanças. ao abordar a questão cíclica entre scriptpubkeys e txids, a abordagem do apo é excluir informações relevantes de entrada e assinar apenas as saídas, permitindo que as transações se vinculem dinamicamente a diferentes utxos.

logicamente, a operação de verificação de assinatura op_checksig (e suas variantes) realiza três funções:

1. montando as partes da transação de gastos.
2. hashando eles.
3. verificando se o hash foi assinado por uma chave dada.

os detalhes da assinatura têm muita flexibilidade, com a decisão sobre quais campos de transação assinar determinada pela sinalização sighash. de acordo com a definição dos opcodes de assinatura em bip 342, as flags de sighash são divididas em sighash_all, sighash_none, sighash_single e sighash_anyonecanpay. sighash_anyonecanpay controla as entradas, enquanto as outras controlam as saídas.

sighash_all é a sinalização padrão de sighash, assinando todas as saídas; sighash_none não assina nenhuma saída; sighash_single assina uma saída específica. sighash_anyonecanpay pode ser configurado com as primeiras três sinalizações de sighash. Se sighash_anyonecanpay estiver definido, apenas a entrada especificada é assinada; caso contrário, todas as entradas devem ser assinadas.

claramente, essas bandeiras sighash não eliminam a influência das entradas, mesmo sighash_anyonecanpay, que requer o comprometimento com uma entrada.

Assim, o bip 118 propõe o sighash_anyprevout. A assinatura apo não precisa se comprometer com o utxo de entrada gasto (conhecido como prevout), mas apenas precisa assinar as saídas, fornecendo maior flexibilidade no controle do Bitcoin. Ao pré-construir transações e criar chaves públicas e assinaturas 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, implementando assim um acordo. A flexibilidade do apo também pode ser usada para reparo de transações; se uma transação estiver presa na cadeia devido a baixas taxas, outra transação pode ser facilmente criada para aumentar a taxa sem precisar de uma nova assinatura. Além disso, para carteiras multiassinatura, não depender das entradas gastas torna as operações mais convenientes.

uma vez que elimina o ciclo entre scriptpubkeys e input txids, apo pode realizar introspecção adicionando dados de saída na testemunha, embora isso ainda exija consumo adicional de espaço de testemunha.

Para protocolos off-chain, como a rede Lightning e os cofres, o APO reduz a necessidade de salvar estados intermediários, reduzindo consideravelmente os requisitos e a complexidade do armazenamento. O caso de uso mais direto da APO é o Eltoo, que simplifica as fábricas de canais, constrói torres de vigia leves e baratas e permite saídas unilaterais sem deixar estados errôneos, melhorando o desempenho da rede Lightning de muitas maneiras. O APO também pode ser usado para simular funções de CTV, embora exija que os indivíduos armazenem assinaturas e transações pré-assinadas, o que é mais caro e menos eficiente do que o CTV.

A principal crítica do Apo diz respeito à necessidade de uma nova versão de chave, que não pode ser implementada simplesmente sendo retrocompatível. Além disso, o novo tipo de hash de assinatura pode introduzir potenciais riscos de gastos duplos. Após extensas discussões na comunidade, o Apo adicionou assinaturas regulares sobre o mecanismo de assinatura original para aliviar preocupações de segurança, ganhando assim o código bip-118.

op_vault bip-345

bip-345 propõe a adição de dois novos opcodes, op_vault e op_vault_recover, que, combinados com ctv, implementam um pacto especializado que permite aos usuários impor um atraso na despesa de moedas específicas. Durante este atraso, uma transação previamente feita pode ser "revertida" através de um caminho de recuperação.

Os usuários podem criar um cofre criando um endereço taproot específico que deve conter pelo menos dois scripts em seu mastro: um com o opcode op_vault para facilitar o processo de retirada esperado, e outro com o opcode op_vault_recover para garantir que as moedas possam ser recuperadas a qualquer momento antes da conclusão da retirada.

como o op_vault implementa saques com bloqueio de tempo interrompível? o op_vault consegue isso substituindo o script op_vault gasto por um script especificado, atualizando efetivamente uma única folha do mastro, deixando as demais folhas do taproot inalteradas. esse projeto é semelhante ao tluv, exceto que op_vault não suporta atualizações para a chave interna.

ao introduzir um modelo durante o processo de atualização do script, é possível limitar os pagamentos. O parâmetro time-lock é especificado por op_vault, e o modelo do opcode ctv restringe o conjunto de saídas que podem ser gastas por meio desse caminho de script.

bip-345 é projetado especificamente para cofres, alavancando op_vault e op_vault_recover para fornecer aos usuários um método custodial seguro que utiliza uma chave altamente segura (como uma carteira de papel ou um multisig distribuído) como um caminho de recuperação, enquanto configura um certo atraso para pagamentos regulares. Os dispositivos dos usuários monitoram continuamente os gastos do cofre e, se ocorrer uma transferência inesperada, os usuários podem iniciar uma recuperação.

a implementação do cofre via bip-345 requer consideração de problemas de custo, especialmente para transações de recuperação. possíveis soluções incluem cpfp (criança paga pelo pai), âncoras temporárias e novas bandeiras de hash de assinatura de grupo sighash.

tluv (tapleafupdateverify)

O esquema tluv é construído em torno de Taproot e tem como objetivo resolver de forma eficiente o problema de saída de UTXOs compartilhados. O princípio orientador é que, quando uma saída de Taproot é gasta, atualizações parciais podem ser feitas na chave interna e no mastro (trie tapscript) por meio de transformações criptográficas e da estrutura interna do endereço Taproot, conforme descrito pelo script tluv. Isso permite a implementação de funções do pacto.

O conceito do esquema TLUV é criar um novo endereço taproot com base na entrada de gastos atual, introduzindo um novo opcode, tapleaf_update_verify. Isso pode ser alcançado executando uma ou mais das seguintes ações:

1. atualizar a chave pública interna
2. cortar o caminho de Merkle
3. remover o script atualmente em execução
4. adicionar um novo passo no final do caminho de Merkle

especificamente, tluv aceita três entradas:

1. um que especifica como atualizar a chave pública interna.
2. um que especifica um novo passo para o caminho de Merkle.
3. um que especifica se deve remover o script atual e/ou quantos passos do caminho de merkle devem ser cortados.

o opcode tluv calcula o scriptpubkey atualizado e verifica se a saída correspondente à entrada atual é gasta para este scriptpubkey.

O TLUV é inspirado no conceito de Coinpool. Hoje, os pools conjuntos podem ser criados usando apenas transações pré-assinadas, mas se as saídas não permitidas forem realizadas, será necessário criar um número exponencialmente crescente de assinaturas. O TLUV, no entanto, permite saídas não permitidas sem pré-assinaturas. Por exemplo, um grupo de parceiros poderia usar o Taproot para construir um UTXO compartilhado, reunindo seus fundos. Eles podem mover fundos internamente usando a chave Taproot ou assinar em conjunto para iniciar pagamentos externamente. Os indivíduos podem sair do pool de fundos compartilhados a qualquer momento, removendo seus caminhos de pagamento, enquanto outros ainda podem concluir pagamentos pelos caminhos originais, e a saída do indivíduo não expõe informações adicionais sobre outros dentro. Esse modo é mais eficiente e privado em comparação com transações não agrupadas.

A operação tluv alcança restrições de gastos parciais atualizando a tentativa taproot original, porém, não implementa a introspecção do valor de saída. Portanto, uma nova operação, in_out_amount, também é necessária. Esta operação empurra dois itens para a pilha: o valor do utxo para esta entrada e o valor para a saída correspondente, então aqueles que usam tluv são esperados a usar operadores matemáticos para verificar que os fundos são retidos de forma adequada no scriptpubkey atualizado.

a introspecção dos montantes de saída adiciona complexidade porque os montantes em satoshis precisam de até 51 bits para serem representados, mas os scripts permitem apenas operações matemáticas de 32 bits. isso requer redefinir o comportamento do opcode para atualizar os operadores em scripts ou usar sighash_group para substituir in_out_amount.

tluv tem potencial como uma solução para pools de financiamento de camada 2 descentralizados, embora a confiabilidade ao ajustar a árvore de raiz do torneira ainda precise de confirmação.

matt

matt (merkleize all the things) tem como objetivo alcançar três objetivos: merkleizar o estado, merkleizar o script e merkleizar a execução, possibilitando assim contratos inteligentes universais.

1. merkleizando o estado: isso envolve a construção de uma trie merkle, onde cada nó folha representa o hash de um estado, com a raiz merkle incorporando o estado geral do contrato.
2. merkleizando o script: isso se refere à formação de um mastro usando o tapscript, onde cada nó folha representa um possível caminho de transição de estado.
3. execução de merkleização: a execução é merkleizada por meio de compromissos criptográficos e um mecanismo de desafio de fraude. para qualquer função computacional, os participantes podem calcular off-chain e depois publicar um compromisso, f(x)=y. se outros participantes encontrarem um resultado errôneo, f(x)=z, eles podem iniciar um desafio. a arbitragem é conduzida por meio de busca binária, semelhante ao princípio do rollup otimista.

Merkleizing a execução

para implementar matt, a linguagem de script do bitcoin precisa ter as seguintes funcionalidades:

1. forçar uma saída a ter um determinado script (e seus valores)
2. anexar um pedaço de dados a uma saída
3. ler os dados da entrada atual (ou de outra)

o segundo ponto é crucial: os dados dinâmicos significam que o estado pode ser calculado por meio de dados de entrada fornecidos pelo gastador, pois isso permite a simulação de uma máquina de estados, capaz de determinar o próximo estado e dados adicionais. o esquema matt implementa isso através do opcode op_checkcontractverify (op_ccv), uma fusão dos opcodes op_checkoutputcontractverify e op_checkinputcontractverify previamente propostos, usando um parâmetro de flags adicional para especificar o alvo da operação.

controle sobre quantidades de saída: o método mais direto é a introspecção direta; no entanto, as quantidades de saída são números de 64 bits, exigindo aritmética de 64 bits, o que representa uma complexidade significativa no script do Bitcoin. op_ccv adota uma abordagem de verificação adiada, como op_vault, onde todas as entradas para a mesma saída com ccv têm suas quantidades de entrada somadas, servindo como um limite inferior para a quantidade de saída. o adiamento ocorre porque esta verificação ocorre durante o processo de transação, em vez de durante a avaliação do script das entradas.

dada a universalidade das provas de fraude, certas variantes do contrato matt devem ser capazes de implementar todos os tipos de contratos inteligentes ou construções de camada 2, embora requisitos adicionais (como bloqueio de capital e atrasos no período de desafio) precisem ser avaliados com precisão; mais pesquisas são necessárias para avaliar quais aplicações são aceitáveis para transações. por exemplo, usando compromissos criptográficos e mecanismos de desafio de fraude para simular a função op_zk_verify, alcançando rollups sem confiança no Bitcoin.

na prática, as coisas já estão acontecendo. Johan Torås Halseth utilizou o opcode op_checkcontractverify da proposta de soft fork do Matt para implementarelftrace, que permite que qualquer programa que suporte a compilação risc-v seja verificado na cadeia de blocos do Bitcoin, permitindo que uma parte dentro de um protocolo de contrato acesse fundos por meio da verificação do contrato, assim, conectando a verificação nativa do Bitcoin.

csfs (op_checksigfromstack)

a partir da introdução do opcode apo, aprendemos que op_checksig (e suas operações relacionadas) são responsáveis por montar transações, hash e verificar assinaturas. no entanto, a mensagem verificada por essas operações é derivada da serialização da transação usando o opcode e não permite especificar nenhuma outra mensagem. em termos simples, op_checksig (e suas operações relacionadas) servem para verificar, por meio do mecanismo de assinatura, se o utxo sendo gasto como entrada de transação foi autorizado a ser gasto pelo detentor da assinatura, protegendo assim a segurança do Bitcoin.

csfs, como o nome sugere, verifica a assinatura da pilha. O opcode 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 as pessoas podem passar qualquer mensagem para a pilha através da testemunha e verificá-la através do csfs, permitindo algumas inovações no Bitcoin.

A flexibilidade do CSFS permite implementar mecanismos, como assinaturas de pagamento, delegação de autorização, contratos de oráculo, títulos de proteção contra gastos duplos e, mais importante, introspecção de transação. O princípio de usar CSFS para introspecção de transação é bastante simples: se o conteúdo da transação usado por op_checksig for empurrado para a pilha por meio da testemunha e a mesma chave pública e assinatura forem usadas para verificar ambas com op_csfs e op_checksig, e se ambas as verificações passarem com êxito, então o conteúdo da mensagem arbitrária passada para op_csfs é o mesmo que a transação gasta serializada (e outros dados) implicitamente usados por op_checksig. Em seguida, obtemos dados de transação verificados na pilha, que podem ser usados para aplicar restrições às transações de gastos com outros opcodes.

csfs muitas vezes aparece junto com op_cat porque op_cat pode conectar diferentes campos da transação para completar a serialização, permitindo uma seleção mais precisa dos campos de transação necessários para a introspecção. sem op_cat, o script não pode recalcular o hash a partir de dados que podem ser verificados separadamente, então o que ele pode realmente fazer é verificar se o hash corresponde a um valor específico, o que significa que as moedas só podem ser gastas através de uma transação específica única.

CSFs podem implementar opcodes como CLTV, CSV, CTV, APO, etc., tornando-se um opcode de introspecção versátil. Assim, também auxilia nas soluções de escalabilidade para Bitcoin Layer2. A desvantagem é que requer a adição de uma cópia completa da transação assinada na pilha, o que pode aumentar significativamente o tamanho das transações destinadas à introspecção usando CSFs. Em contraste, opcodes de introspecção de propósito único como CLTV e CSV têm sobrecarga mínima, mas adicionar cada novo opcode de introspecção especial requer mudanças de consenso.

txhash (op_txhash)

op_txhash é um código operacional com capacidade de introspecção direta que permite ao operador selecionar e empurrar o hash de um campo específico para a pilha. Especificamente, op_txhash retira um sinalizador de txhash da pilha e calcula um txhash (marcado) com base nesse sinalizador, em seguida, empurra o hash resultante de volta para a pilha.

devido às semelhanças entre txhash e ctv, surgiu uma quantidade considerável de discussão dentro da comunidade sobre os dois.

txhash pode ser considerado um upgrade universal do ctv, oferecendo um modelo de transação mais avançado que permite aos usuários especificar partes de uma transação de gasto explicitamente, abordando muitas questões relacionadas às taxas de transação. Ao contrário de outros opcodes de convenção, txhash não requer uma cópia dos dados necessários na testemunha, reduzindo ainda mais os requisitos de armazenamento; ao contrário do ctv, txhash não é compatível com nop e só pode ser implementado em tapscript; a combinação de txhash e csfs pode servir como uma alternativa ao ctv e apo.

do ponto de vista da construção de pactos, o txhash é mais propício para a criação de 'pactos aditivos', onde todas as partes dos dados da transação que você deseja fixar são empurradas para a pilha, hash juntas e o hash resultante é verificado para corresponder a um valor fixo; ctv é mais adequado para criar 'pactos subtrativos', onde todas as partes dos dados da transação que você deseja manter livres são empurradas para a pilha. então, usando um opcode de rolling sha256, o hash começa a partir de um estado intermediário fixo que se compromete com um prefixo dos dados do hash da transação. as partes livres são hashadas neste estado intermediário.

o campo txfieldselector definido na especificação txhash espera-se que seja expandido para outros opcodes, como op_tx.

o BIP relacionado ao txhash está atualmente no status de rascunho no GitHub e ainda não recebeu um número atribuído.

op_cat

op_cat é um opcode envolto em mistério, originalmente abandonado por satoshi nakamoto devido a preocupações com a segurança, ele recentemente provocou intensas discussões entre os desenvolvedores principais do bitcoin e até mesmo estimulou a cultura de memes na internet. No final, o op_cat foi aprovado sob o bip-347 e foi chamado de proposta bip mais provável de passar nos tempos recentes.

na verdade, o comportamento de op_cat é bastante simples: ele concatena dois elementos da pilha. como isso permite a funcionalidade do convênio?

de fato, a capacidade de concatenar dois elementos corresponde a uma poderosa estrutura de dados criptográficos: a trie de merkle. para construir uma trie de merkle, apenas operações de concatenação e hash são necessárias, e as funções hash estão disponíveis em scripts de bitcoin. assim, com op_cat, teoricamente podemos verificar provas de merkle dentro de scripts de bitcoin, que é um dos métodos de verificação leve mais comuns na tecnologia blockchain.

Como mencionado anteriormente, os QCA, com a ajuda de op_cat, podem implementar um esquema de pacto universal. Na verdade, sem CSFs, aproveitando a estrutura das assinaturas Schnorr, op_cat si pode alcançar a introspecção de transações.

em assinaturas schnorr, a mensagem que precisa ser assinada é composta pelos seguintes campos:

Esses campos contêm os principais elementos de uma transação. Colocando-os no scriptPubKey ou Witness e usando op_cat combinados com op_sha256, podemos construir uma assinatura Schnorr e verificá-la usando op_checksig. Se a verificação for aprovada, a pilha reterá os dados de transação verificados, alcançando a introspecção da transação. Isso nos permite extrair e "verificar" várias partes da transação, como suas entradas, saídas, endereços de destino ou os valores de bitcoin envolvidos.

para princípios criptográficos específicos, pode-se consultar o artigo de andrew poelstra, 'tricks cat and schnorr'.

em resumo, a versatilidade do op_cat permite que ele emule quase qualquer opcode de pacto. uma infinidade de opcodes de pacto dependem da funcionalidade do op_cat, o que avança significativamente sua posição na lista de fusão. teoricamente, contando apenas com op_cat e os opcodes de bitcoin existentes, temos esperança de construir um btc zk rollup com confiança mínima. starknet, chakra e outros parceiros do ecossistema estão trabalhando ativamente para que isso aconteça.

conclusão

à medida que exploramos as diversas estratégias para dimensionar o Bitcoin e aprimorar sua programabilidade, fica claro que o caminho a seguir envolve uma combinação de melhorias nativas, cálculos fora da cadeia e recursos de script sofisticados.

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

A escalabilidade de computação fora da cadeia é o futuro, mas a programabilidade do Bitcoin precisa avançar para melhor apoiar essa escalabilidade e se tornar uma verdadeira moeda global.

no entanto, a natureza da computação no bitcoin é fundamentalmente diferente daquela no ethereum. o bitcoin suporta apenas a “verificação” como forma de computação e não pode realizar computações gerais, enquanto o ethereum é intrinsecamente computacional, sendo a verificação um subproduto da computação. essa diferença é evidente em um ponto: o ethereum cobra uma taxa de gás para transações que não são executadas, enquanto o bitcoin não.

alianças representam uma forma de contrato inteligente baseada em verificação em vez de computação. Exceto por alguns fundamentalismos de satoshi, parece que todos consideram alianças uma boa escolha para melhorar o Bitcoin. No entanto, a comunidade continua a debater acirradamente sobre qual abordagem deve ser usada para implementar alianças.

APO, op_vault e TLUV inclinam-se para aplicações diretas, e escolhê-las pode alcançar aplicações específicas de uma maneira mais barata e eficiente. Os entusiastas da Lightning Network preferem o APO para alcançar a simetria do LN; aqueles que procuram implementar um cofre seriam mais bem servidos por op_vault; Para construir Coinpool, o TLUV oferece mais privacidade e eficiência. op_cat e txhash são mais versáteis, com menor probabilidade de vulnerabilidades de segurança, e podem implementar mais casos de uso quando combinados com outros opcodes, talvez ao custo da complexidade do script. CTV e CSFs ajustaram o processamento de blockchain, com CTV implementando saídas atrasadas e CSFs implementando assinaturas atrasadas. Matt se destaca com sua estratégia de execução otimista e provas de fraude, utilizando a estrutura do Merkle Trie para implementar contratos inteligentes universais, embora ainda exija novos opcodes para recursos introspectivos.

vemos que a comunidade do Bitcoin está discutindo ativamente a possibilidade de obter pactos por meio de um soft fork. A Starknet anunciou oficialmente sua entrada no ecossistema do Bitcoin, planejando implementar acordos na rede do Bitcoin dentro de seis meses após a fusão do op_cat. A Chakra continuará monitorando os últimos desenvolvimentos no ecossistema do Bitcoin, pressionando pela fusão do soft fork op_cat e aproveitando a programabilidade trazida pelos pactos para construir uma camada de liquidação do Bitcoin mais segura e eficiente.

disclaimer：

1. este artigo é reproduzido a partir de [Espelho]. todos os direitos autorais pertencem ao autor original [chakra]. se houver objeções a esta reedição, entre em contato com oAprender Gateequipe e eles lidarão com isso prontamente.
2. isenção de responsabilidade: as opiniões expressas neste artigo são exclusivamente do autor e não constituem qualquer conselho de investimento.
3. as traduções do artigo para outros idiomas são feitas pela equipe de aprendizado da Gate.io. A menos que mencionado, copiar, distribuir ou plagiar os artigos traduzidos é proibido.