visão geral

Em comparação com blockchains Turing-complete como o Ethereum, o script Bitcoin é considerado altamente restritivo, capaz apenas de operações básicas, e até mesmo não tem suporte para multiplicação e divisão. Mais importante ainda, os próprios dados do blockchain são quase inacessíveis aos scripts, resultando em uma falta significativa de flexibilidade e programação. Portanto, há um esforço de longa data para permitir que os scripts do Bitcoin alcancem a introspeção.

a introspecção refere-se à capacidade dos scripts bitcoin de 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, permitindo funcionalidades mais complexas. atualmente, a maioria dos opcodes 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 timestamps, quantidades, txid, etc.) para a pilha, permitindo um controle mais granular sobre a despesa de utxo.

até agora, apenas três opcodes principais em bitcoin scripting suportam introspecção: checklocktimeverify, checksequenceverify e checksig, juntamente com suas variantes checksigverify, checksigadd, checkmultisig e checkmultisigverify.

pacto, em termos simples, refere-se a restrições sobre como as moedas são transferidas, permitindo aos usuários especificar como utxos são distribuídos. muitos pactos são implementados através de opcodes de introspecção, e as discussões sobre introspecção agora foram categorizadas sob o tópico de pactos em Optech Bitcoin.

o bitcoin atualmente tem dois pactos, csv (verificação de sequência de cheque) e cltv (verificação de tempo de bloqueio), ambos pactos baseados no 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 à transferência de moedas? No criptoespaço, nosso método mais comum é por meio de compromissos, frequentemente implementados por meio de hashes. Para provar que os requisitos de transferência são atendidos, também são necessários mecanismos de assinatura para verificação. Assim, muitos ajustes de hashes e assinaturas existem dentro dos convênios.

abaixo, descreveremos a amplamente discutida proposta de operação de código de aliança.

ctv (verificação de modelo de verificação) bip-119

ctv (checktemplateverify) é uma proposta de atualização do bitcoin contida no bip-119 que tem atraído 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, contagem de inputs, sequences hash, contagem de outputs, outputs hash, índice de input. 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 input. Isso efetivamente confina o tempo, método e valor de transações futuras desse utxo.

notavelmente, o txid de entrada é excluído deste hash. esta exclusão é necessária, pois em transações legadas 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 construí-lo.

ctv implementa a introspecção puxando diretamente as informações de transação especificadas para o hash e comparando-as com o compromisso na pilha. Este método de introspecção é menos exigente em termos de espaço na cadeia, mas falta alguma flexibilidade.

a base das soluções de segunda camada do bitcoin, como a lightning network, são transações pré-assinadas. A pré-assinatura normalmente refere-se à geração e assinatura de transações antecipadamente, mas sem as transmitir até que certas condições sejam atendidas. Essencialmente, ctv implementa uma forma mais rigorosa de pré-assinatura, publicando o compromisso de pré-assinatura na cadeia, restrita ao modelo predefinido.

ctv foi inicialmente proposto para aliviar a congestão no Bitcoin, que também pode ser referida como controlo de congestionamento. Durante períodos de grande congestionamento, ctv pode comprometer-se com múltiplas transações futuras dentro de uma única transação, evitando a necessidade de transmitir múltiplas transações durante os horários de pico e completando as transações reais uma vez que a congestão diminui. Isto poderia ser particularmente útil durante 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. Uma vez que a direção dos fundos está predeterminada, os hackers não podem direcionar utxos usando scripts ctv para os seus próprios endereços.

ctv pode melhorar 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 do 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 de entrada relevantes 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. hashing them.
3. verificando se o hash foi assinado por uma chave específica.

os detalhes da assinatura têm muita flexibilidade, com a decisão sobre quais campos de transação assinar determinados pela bandeira sighash. de acordo com a definição de códigos de operação de assinatura no bip 342, as bandeiras 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 é o sinalizador 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 definido com os três primeiros sinais de sighash. Se sighash_anyonecanpay for definido, apenas a entrada especificada será assinada; caso contrário, todas as entradas devem ser assinadas.

Claramente, essas flags do sighash não eliminam a influência das entradas, mesmo o sighash_anyonecanpay, que requer comprometer-se a 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, proporcionando 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 pacto. a flexibilidade do apo também pode ser usada para reparo de transações; se uma transação estiver presa na cadeia devido a taxas baixas, 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, o apo pode realizar introspeção adicionando dados de saída na testemunha, embora isso ainda exija consumo adicional de espaço da testemunha.

para protocolos off-chain como a rede lightning e cofres, apo reduz a necessidade de salvar estados intermediários, reduzindo significativamente os requisitos de armazenamento e complexidade. O uso mais direto de apo é eltoo, que simplifica 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 várias maneiras. apo também pode ser usado para simular funções ctv, embora exija que os indivíduos armazenem assinaturas e transações pré-assinadas, o que é mais caro e menos eficiente do que ctv.

A principal crítica da apo centra-se na necessidade de uma nova versão da 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, a apo acrescentou assinaturas regulares por cima do mecanismo original de assinatura para mitigar as 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 especial que permite aos utilizadores impor um atraso na despesa de moedas específicas. Durante este atraso, uma transação previamente efetuada pode ser "revertida" através de um caminho de recuperação.

os utilizadores podem criar um cofre criando um endereço específico de taproot que deve conter pelo menos dois scripts no seu mastro: um com o opcode op_vault para facilitar o processo de levantamento esperado e outro com o opcode op_vault_recover para garantir que as moedas possam ser recuperadas a qualquer momento antes da conclusão do levantamento.

como o op_vault implementa retiradas com bloqueio de tempo interrompível? o op_vault realiza isso substituindo o script op_vault gasto por um script especificado, atualizando efetivamente uma única folha do mastro enquanto mantém inalterados os demais nós folha do taproot. esse design é semelhante ao tluv, exceto que o 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 de bloqueio de tempo é especificado por op_vault, e o modelo do opcode ctv restringe o conjunto de saídas que podem ser gastas através deste caminho de script.

bip-345 é projetado especificamente para cofres, aproveitando op_vault e op_vault_recover para fornecer aos usuários um método seguro de custódia que usa uma chave altamente segura (como uma carteira de papel ou uma multisig distribuída) 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 questões 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 sighash_group.

tluv (tapleafupdateverify)

o esquema tluv é construído em torno do taproot e tem como objetivo resolver eficientemente o problema de saída dos utxos compartilhados. o princípio orientador é que quando uma saída taproot é gasta, podem ser feitas atualizações parciais para a chave interna e mast (árvore de script de toque) através 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 de convênio.

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. uma que especifica se deve remover o script atual e/ou quantos passos do caminho de Merkle serem cortados.

a operação tluv calcula a scriptpubkey atualizada e verifica se a saída correspondente à entrada atual é gasta nesta scriptpubkey.

tluv é inspirado no conceito de coinpool. hoje em dia, pools conjuntas podem ser criadas apenas usando transações pré-assinadas, mas se saídas não autorizadas forem realizadas, seria necessário criar um número exponencialmente crescente de assinaturas. tluv, no entanto, permite saídas não autorizadas sem nenhuma pré-assinatura. por exemplo, um grupo de parceiros poderia usar taproot para construir um utxo compartilhado, juntando seus fundos. eles podem mover fundos internamente usando a chave taproot ou assinar conjuntamente para iniciar pagamentos externamente. indivíduos podem sair do pool de fundos compartilhados a qualquer momento, removendo seus caminhos de pagamento, enquanto outros ainda podem completar pagamentos através dos caminhos originais, e a saída do indivíduo não expõe informações adicionais sobre outros envolvidos. esse modo é mais eficiente e privado em comparação com transações não agrupadas.

o opcode tluv alcança restrições parciais de gastos atualizando a tentativa de taproot original, mas não implementa a introspecção do valor de saída. portanto, também é necessário um novo opcode, in_out_amount. este opcode 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 devem usar operadores matemáticos para verificar que os fundos são retidos adequadamente no scriptpubkey atualizado.

a introspeção dos montantes de saída acrescenta 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 operadores nos 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 o trie taproot ainda precise de confirmação.

mate

matt (merkleize todas as coisas) tem como objetivo alcançar três objetivos: merkleizar o estado, merkleizar o script e merkleizar a execução, permitindo assim contratos inteligentes universais.

1. merkleizar o estado: isso envolve a construção de uma árvore de merkle, onde cada nó folha representa o hash de um estado, com a raiz de merkle incorporando o estado geral do contrato.
2. merkleizando o script: isto refere-se à formação de um mastro usando 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 através de compromissos criptográficos e de um mecanismo de desafio de fraude. para qualquer função computacional, os participantes podem computar 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 é realizada através de busca binária, semelhante ao princípio do rollup otimista.

merkleizando a execução

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

1. forçar uma saída a ter um determinado script (e seus montantes)
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 através de dados de entrada fornecidos pelo gastador, uma vez que 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 previamente propostos op_checkoutputcontractverify e op_checkinputcontractverify, 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 apresenta complexidade significativa na criação de scripts do Bitcoin. op_ccv adota uma abordagem de verificação adiada, como op_vault, onde todos os inputs para a mesma saída com ccv têm suas quantidades de input somadas, servindo como limite inferior para a quantidade dessa saída. O adiamento ocorre porque essa verificação ocorre durante o processo de transação, em vez de durante a avaliação do script dos inputs.

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 confiáveis no bitcoin.

Na prática, as coisas já estão a acontecer. Johan Torås Halseth utilizou o op_checkcontractverify opcode da proposta Matt Soft Fork para implementar elftrace, que permite que qualquer programa que suporte a compilação risc-v seja verificado na blockchain do Bitcoin, permitindo a uma parte dentro de um protocolo de contrato aceder a fundos através da verificação do contrato, assim fazendo a ligação à 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, fazer 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 qualquer outra mensagem. em termos simples, op_checksig (e suas operações relacionadas) servem para verificar, por meio do mecanismo de assinatura, se o utxo 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, possibilitando algumas inovações no Bitcoin.

A flexibilidade dos csfs permite a implementação de mecanismos como assinaturas de pagamento, delegação de autorização, contratos de oráculo, proteção contra gastos duplos e, mais importante, introspecção de transações. O princípio de usar csfs para introspecção de transações é 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 ambos com op_csfs e op_checksig, e se ambas as verificações passarem com sucesso, então o conteúdo da mensagem arbitrário passada para op_csfs é o mesmo que a transação de gasto serializada (e outros dados) implicitamente usada por op_checksig. Em seguida, obtemos dados de transação verificados na pilha, que podem ser usados para aplicar restrições a transações de gasto com outros opcodes.

csfs aparece frequentemente 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 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 realmente pode 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 pode implementar opcodes como cltv, csv, ctv, apo, etc., tornando-se um opcode de introspecção versátil. assim, também ajuda nas soluções de escalabilidade para a camada 2 do Bitcoin. 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 uso único como cltv e csv têm um overhead mínimo, mas a adição de cada novo opcode especial de introspecção requer mudanças de consenso.

txhash (op_txhash)

op_txhash é um opcode habilitado para 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 em relação aos 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 gastos de forma explícita, abordando muitos problemas relacionados às taxas de transação. Ao contrário de outros códigos de convênio, 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 covenants, txhash é mais adequado para criar 'covenants aditivos', onde todas as partes dos dados da transação que você deseja corrigir são empurradas para a pilha, hashadas juntas e o hash resultante é verificado para corresponder a um valor fixo; ctv é mais adequado para criar 'covenants 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 rolling sha256, o hashing começa 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 nesse 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.

op_cat

op_cat é um opcode envolto em mistério, originalmente abandonado por satoshi nakamoto devido a preocupações com segurança, recentemente tem gerado intensa discussão entre os desenvolvedores principais do bitcoin e até mesmo impulsionou a cultura de memes na internet. no final, op_cat foi aprovado sob o bip-347 e tem sido chamado de proposta bip mais provável de ser aprovada nos tempos recentes.

Na verdade, o comportamento do op_cat é bastante simples: ele concatena dois elementos da pilha. Como é que ele permite a funcionalidade do pacto?

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

como mencionado anteriormente, csfs, com a ajuda do op_cat, pode implementar um esquema de convênio universal. na verdade, sem csfs, alavancando a estrutura das assinaturas schnorr, o próprio op_cat pode alcançar a introspecção da transação.

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

estes campos contêm os principais elementos de uma transação. ao colocá-los no scriptpubkey ou testemunha e usando o op_cat combinado com o op_sha256, podemos construir uma assinatura schnorr e verificá-la usando o op_checksig. se a verificação for bem-sucedida, a pilha retém os dados da 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 montantes de bitcoin envolvidos.

para princípios criptográficos específicos, pode-se consultar o artigo de andrew poelstra, "truques de cat e schnorr".

Em resumo, a versatilidade do op_cat permite que ele emule quase qualquer opcode de convênio. Uma multidão de opcodes de convênio depende da funcionalidade do op_cat, o que avança significativamente sua posição na lista de fusão. Teoricamente, confiando apenas no op_cat e nos opcodes existentes do Bitcoin, estamos esperançosos de construir um btc zk rollup com minimização de confiança. Starknet, Chakra e outros parceiros do ecossistema estão ativamente pressionando para que isso aconteça.

conclusão

à medida que exploramos as diversas estratégias para escalar o Bitcoin e melhorar a sua programabilidade, torna-se claro que o caminho a seguir envolve uma combinação de melhorias nativas, cálculos fora da cadeia e capacidades de script sofisticadas.

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

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

contudo, a natureza da computação no Bitcoin é fundamentalmente diferente daquela no Ethereum. O Bitcoin apenas suporta a “verificação” como forma de computação e não consegue realizar cálculos gerais, enquanto o Ethereum é inerentemente computacional, sendo a verificação um subproduto da computação. Esta diferença é evidente a partir de um ponto: o Ethereum cobra uma taxa de gás para transações que falham ao executar, enquanto o Bitcoin não o faz.

os convénios representam uma forma de contrato inteligente baseada na verificação em vez de na computação. Exceto por alguns fundamentalismos satoshi, parece que todos consideram os convénios uma boa escolha para melhorar o bitcoin. No entanto, a comunidade continua a debater ferozmente sobre qual abordagem deve ser usada para implementar os convénios.

apo, op_vault e tluv inclinam-se para aplicações diretas, e escolher estes pode alcançar aplicações específicas de forma mais barata e eficiente. Os entusiastas da rede Lightning prefeririam apo para alcançar a simetria ln; aqueles que procuram implementar uma vault seriam melhor servidos por op_vault; para a construção de coinpool, tluv oferece mais privacidade e eficiência. op_cat e txhash são mais versáteis, com uma 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 da blockchain, com ctv implementando outputs atrasados e csfs implementando assinaturas atrasadas. matt destaca-se com sua estratégia de execução otimista e provas de fraude, utilizando a estrutura do trie de merkle para implementar smart contracts universais, embora ainda requeira novos opcodes para capacidades introspectivas.

vemos que a comunidade do Bitcoin está discutindo ativamente a possibilidade de obter convênios por meio de um soft fork. O Starknet anunciou oficialmente sua entrada no ecossistema do Bitcoin, planejando implementar liquidações 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, promovendo a fusão do soft fork do op_cat e aproveitando a programabilidade trazida pelos convênios 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 de autor pertencem ao autor original [chakra]. se houver objeções a esta reimpressão, entre em contato com oGate aprenderequipa e eles tratarão do assunto prontamente.
2. aviso de responsabilidade: as opiniões e pontos de vista expressos neste artigo são exclusivamente os 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 seja mencionado, copiar, distribuir ou plagiar os artigos traduzidos é proibido.