Os 'Covenants' do Bitcoin são mecanismos que estabelecem condições para transações futuras de Bitcoin. O artigo delineia os conceitos básicos, cenários de aplicação e métodos de implementação técnica das cláusulas de restrição, e discute os princípios de design por trás delas. Propostas técnicas como OP_CAT, OP_CTV e APO são introduzidas, e como elas aprimoram a programabilidade e funções de contratos inteligentes do Bitcoin. Ao mesmo tempo, o artigo também aborda a aplicação de cláusulas de restrição na rede Bitcoin, como controle de congestionamento, cofres, canais de status, etc., e discute as ideias de design para implementar cláusulas de restrição e potenciais disputas comunitárias.

Co-escrito porJeffrey HueHarper Li

Houve recentemente uma onda de discussão na comunidade do Bitcoin sobre a reabilitação de códigos de operação como OP_CAT, e o Taproot Wizard atraiu muita atenção ao lançar o NFT Quantum Cats, afirmando ter recebido a atribuição BIP-420. Os defensores afirmam que a ativação do OP_CAT vai realizar “pactos”, e assim trazer contratos inteligentes ou programabilidade no Bitcoin.

Se reparar na palavra “pactos” e fizer uma pequena pesquisa, verá que este é outro grande buraco de coelho. Os desenvolvedores têm falado há anos sobre tecnologias que implementam pactos, como OP_CTV, APO, OP_VAULT e outros, para além de OP_CAT.

Mais precisamente, os scripts atuais do Bitcoin também possuem alguns tipos de acordos, como bloqueios de tempo baseados em opcode, que são implementados pela introspeção do campo nLock ou nSequence de uma transação para limitar a quantidade de tempo antes que a transação possa ser gasta, mas ainda estão apenas limitados às restrições de tempo.

Então, o que são exatamente os “covenants” do Bitcoin? Por que atraiu tanta atenção e discussão de desenvolvedores ao longo dos anos? Que programabilidade do Bitcoin pode ser alcançada? Quais são os princípios de design por trás disso? Este artigo tenta fornecer uma visão geral e discussão.

O que são “Covenants”?

Pacto é um mecanismo que pode definir condições em transações futuras de Bitcoin.

Na verdade, os scripts atuais do Bitcoin contêm restrições, como ter que inserir uma assinatura legítima, enviar scripts compatíveis ao gastar. Desde que o usuário possa desbloqueá-lo, ele pode gastar esse UTXO onde desejar.

O Pacto é impor mais restrições além desta limitação sobre como desbloquear, como limitar os gastos de UTXO depois de serem gastos, o que é para alcançar um efeito semelhante ao da marcação, ou outras condições de entrada inseridas numa transação, etc.

Então, por que os desenvolvedores e pesquisadores projetam essas verificações de restrição? Isso porque os pactos não são apenas restrições sem motivo, mas sim estabelecimento de regras para a execução do comércio. Dessa forma, o usuário só pode executar transações de acordo com as regras predefinidas, completando assim o processo de negócios pretendido.

Assim, de forma bastante contra-intuitiva, isso traz mais cenários de aplicação.

Cenários de Aplicação

Garantindo Penalidades de Staking

Um dos exemplos mais intuitivos de um pacto é a transação de corte de Babilônia no processo de apostar em Bitcoin.

O processo de staking de Bitcoin da Babylon envolve os usuários enviando seu BTC para um script especial na main chain com duas condições de gasto:

• Final feliz: após um certo período de tempo, o usuário pode desbloquear com sua própria assinatura, o que significa que o processo de desbloqueio está completo.
• Final ruim: Se o usuário sofrer um ataque de gasto duplo na cadeia PoS, o usuário pode desbloquear os ativos com sua própria assinatura através do EOTS (assinaturas descartáveis), e uma parte dos ativos pode ser forçada a ser enviada para o endereço de queima (slash) por um ator executante na rede.

Fonte: Bitcoin Staking: Desbloquear 21M Bitcoins para Segurar a Economia de Prova de Participação

Note a palavra "forçado", que significa que mesmo que o UTXO possa ser desbloqueado, o ativo não pode ser enviado para outro lugar, só pode ser queimado. Isso garante que um usuário mal-intencionado não possa escapar transferindo o ativo de volta para si mesmo com sua própria assinatura conhecida.

Este recurso, após a implementação de convénios como OP_CTV, pode ser implementado adicionando opcodes ao "final ruim" do script de staking.

Antes de o OP_CTV ser ativado, Babilónia precisará de uma solução alternativa para emular o efeito de fazer cumprir os pactos, tendo o utilizador + comissão a trabalharem em conjunto.

Controlo de Congestionamento/Escala

Em termos gerais, a congestão ocorre quando a taxa é alta no Bitcoin com um número relativamente grande de transações acumuladas na mempool à espera de serem incluídas, portanto, se um usuário deseja confirmar uma transação rapidamente, ele precisa aumentar a taxa.

Nesse ponto, se um usuário tiver que enviar várias transações para múltiplos endereços, ele terá que aumentar suas taxas e incorrer em custos mais altos. Consequentemente, isso irá aumentar ainda mais a taxa de transação de toda a rede.

Se houver um pacto, então há uma solução: uma única transação comprometida com múltiplas saídas. Este compromisso pode convencer todos os destinatários de que a transação final ocorrerá e todos podem aguardar até que a taxa seja baixa antes de enviar a transação específica.

Como mostrado abaixo, quando a demanda por espaço de bloco é alta, torna-se muito caro realizar transações. Ao usar OP_CHECKTEMPLATEVERIFY, um processador de pagamentos de alto volume pode agregar todos os seus pagamentos em uma única transação O(1) para confirmação. Em seguida, após um período de tempo, quando a demanda por espaço de bloco diminui, os pagamentos podem ser expandidos a partir desse UTXO

Fonte: https://utxos.org/usos/escala/

Este cenário é um dos casos de uso mais típicos apresentados por esta restrição OP_CTV. Muitos mais casos de uso podem ser encontrados emhttps://utxos.org/uses.Para além do controlo de congestionamento mencionado acima, a página lista Apostas Soft Fork, opções descentralizadas, Drivechains, Canais de Lotes, Canais Não Interativos, Piscinas de Mineração Sem Coordenação de Confiança, Cofres, Contratos de Tempo Bloqueados por Hash (HTLCS) Seguros, e mais.

Cofres

Os cofres são um dos casos de uso mais amplamente discutidos das aplicações do Bitcoin, especialmente no âmbito dos pactos. Porque as operações do dia a dia envolvem inevitavelmente o equilíbrio entre a necessidade de manter os fundos seguros e a necessidade de os utilizar, gostaríamos de ter um cofre que possa manter os fundos seguros, ou mesmo restringir o seu uso quando a conta é hackeada (por exemplo, comprometendo a chave privada).

Com base nas técnicas utilizadas para implementar cláusulas de restrição, este tipo de cofre de custódia pode ser construído relativamente facilmente.

Vamos tomar o esquema de design do OP_VAULT como exemplo: ao gastar fundos na vault, uma transação precisa ser enviada para a cadeia primeiro. Esta transação indica a intenção de gastar a vault, que é um “gatilho”, e as condições são definidas nela:

• Se tudo estiver bem, então a segunda transação acabará por levantar os fundos. Após esperar por N blocos, os fundos podem ser gastos em qualquer lugar.
• Se se verificar que a transação foi roubada (ou coagida num “ataque de gatilho”), os ativos podem ser imediatamente enviados para outro endereço seguro (mais seguro para o utilizador) imediatamente antes da transação de levantamento ser enviada após N blocos.

Processo de OP_VAULT ，fonte：BIP-345

Note que também é possível construir um cofre sem acordos, e uma maneira possível de o fazer é usar uma chave privada para preparar uma assinatura para despesas futuras e, em seguida, destruir essa chave privada. No entanto, existem ainda mais limitações, como a necessidade de garantir que a chave privada tenha sido destruída (semelhante ao processo de configuração confiável em provas de conhecimento zero) e a falta de flexibilidade na determinação do montante e da taxa antecipadamente (devido à pré-assinatura).

Cofres pré-calculados e OP_VAULT, origem: BIP-345

Canais de estado mais robustos e flexíveis

Pode geralmente assumir-se que os canais de estado, incluindo a Rede Lightning, têm quase a mesma segurança que a cadeia principal (em termos de garantir que os nós possam observar o estado mais recente e possam publicar corretamente o estado mais recente na cadeia). No entanto, com as convenções, alguns novos designs de canais de estado podem ser feitos em cima da Rede Lightning de forma mais robusta ou flexível. Alguns dos mais conhecidos incluem Eltoo, Ark.

Eltoo (também conhecido como LN-Symmetry) é um exemplo típico. Ao adotar o acrônimo "L2", esta tecnologia propõe uma camada de execução para a Lightning Network que permite que qualquer estado posterior do canal substitua o estado anterior sem um mecanismo de penalização, evitando assim a necessidade de os nós da Lightning Network salvarem múltiplos estados anteriores para evitar que seus adversários cometam atos maliciosos. Para alcançar o efeito acima, Eltoo propõe a assinatura SIGHASH_NOINPUT, APO (BIP-118).

Ark tem como objetivo reduzir a dificuldade de entrada de liquidez e gestão de canais da rede lightning. É um protocolo na forma de joinpool, onde múltiplos utilizadores podem aceitar um fornecedor de serviços como contraparte por um certo período de tempo e negociar vUTXOs (vUTXOs) virtuais fora da cadeia, mas partilhar um UTXO na cadeia para reduzir custos. Semelhante a cofres, Ark pode ser implementado na rede Bitcoin atual; no entanto, com a introdução de convenants, o Ark pode reduzir a quantidade de interação necessária com base em modelos de transação, permitindo uma saída unilateral mais sem confiança.

Visão geral dos pactos

Como se pode ver pelas aplicações acima, as convenants são mais como um efeito do que uma tecnologia específica, e como tal, existem muitas maneiras técnicas de as implementar. Podem ser categorizadas como:

• Tipo: genérico, restritivo
• Implementação: baseada em opcode, baseada em assinatura
• Recursão: recursivo, não recursivo

Aqui, recursivo significa: existem algumas implementações de covenants que também podem limitar a saída da próxima transação, limitando a saída desta transação, o que significa que cada transação na cadeia de transações é restrita pela anterior.

Alguns dos designs de covenants populares incluem:

Desenhos de Alianças

Como se pode ver a partir da introdução anterior, os scripts Bitcoin atuais principalmente restringem as condições para desbloquear e não restringem como esse UTXO pode ser gasto posteriormente. Para implementar convénios, precisamos pensar de forma inversa: por que é que os scripts Bitcoin atuais não podem implementar convénios?

A principal razão é que os scripts atuais do Bitcoin não conseguem ler a própria transação, o que significa a introspeção da transação.

Se pudéssemos implementar introspeção - inspecionando qualquer coisa na transação (incluindo a saída) - então poderíamos implementar pactos.

Assim, o design dos convênios também está centrado em como implementar a introspecção.

Baseado em Opcode vs Baseado em Assinatura

A ideia mais simples e bruta é adicionar um ou mais opcodes (um opcode + múltiplos parâmetros, ou múltiplos opcodes com funções diferentes) e ler o conteúdo da transação diretamente. Isso também é conhecido como a ideia baseada em opcodes.

Outra forma de pensar é que, em vez de ler e verificar o conteúdo da transação diretamente no script, pode ser utilizado o hash do conteúdo da transação, o que significa que se este hash foi assinado, então, ao transformar o opcode como OP_CHECKSIG no script para verificar esta assinatura, é possível implementar indiretamente a introspeção da transação e covenants. Esta ideia baseia-se na abordagem de design de assinatura. Inclui principalmente APO e OP_CSFS.

APO

SIGHASH_ANYPREVOUT (APO) é uma proposta de hash de assinatura. A maneira mais simples de assinar é comprometer tanto as entradas quanto as saídas de uma transação, mas há uma maneira mais flexível para o Bitcoin se comprometer seletivamente com as entradas ou saídas de uma transação, conhecida como SIGHASH.

A atual gama de SIGHASH e suas combinações de assinaturas para as entradas e saídas das transações (fonte: Mastering Bitcoin, 2ª)

Como mostrado acima, além de TODOS, que se aplica a todos os dados, NENHUM é assinado de forma a aplicar-se apenas a todas as entradas e não às saídas, e ÚNICO baseia-se nisso aplicando-se apenas às saídas com o mesmo número de índice de entrada. Além disso, SIGHASH pode ser combinado, com o modificador QUALQUERPESSOAPAGAR superposto, para se aplicar apenas a uma entrada.

O SIGHASH da APO, por outro lado, assina apenas a saída, não a entrada. Isso significa que uma transação assinada com APO pode ser anexada posteriormente a qualquer UTXO que atenda às condições.

Esta flexibilidade é a justificativa por trás da implementação de pactos APO:

• Uma ou mais transações podem ser criadas antecipadamente
• As informações dessas transações são usadas para construir uma chave pública da qual apenas a assinatura de gastos pode ser derivada/verificada
• para que quaisquer ativos enviados para este endereço de chave pública só possam ser gastos através de transações pré-criadas.

Vale ressaltar que, como essa chave pública não tem uma chave privada correspondente, garante que esses ativos só possam ser gastos por meio de transações pré-criadas. Em seguida, podemos implementar um pacto especificando para onde os ativos vão nessas transações pré-criadas.

Isso pode ser melhor entendido ao compará-lo com os contratos inteligentes do Ethereum: o que podemos alcançar com contratos inteligentes é que só podemos retirar dinheiro de um endereço contratado se certas condições forem atendidas, em vez de gastá-lo arbitrariamente com uma assinatura EOA. Sob este ponto de vista, o Bitcoin pode alcançar esse efeito através de melhorias no mecanismo de assinatura.

O problema com o processo acima, no entanto, é que existe um dev@lists.linuxfoundation.org/msg08075.html">dependência circular no cálculo, já que é necessário conhecer a entrada para pré-assinar e criar a transação.

O significado das implementações APO e SIGHASH_NOINPUT deste método de assinatura é que resolve este problema de dependência circular apenas precisando de conhecer (especificar) a saída completa da transação no momento do cálculo.

OP_CTV

OP_CHECKTEMPLATEVERIFY (CTV), ou BIP-119, usa uma melhoria de Opcode. Ele leva o hash de compromisso como argumento e requer que qualquer transação que execute um opcode contenha um conjunto de saídas que correspondam a esse compromisso. Com o CTV, permitiria aos utilizadores de Bitcoin limitar a forma como utilizam o Bitcoin.

Originalmente introduzido como OP_CHECKOUTPUTSHASHVERIFY (COSHV) e com um foco inicial na capacidade de criar transações de controlo de congestionamento, as críticas à proposta também se centraram no facto de não ser suficientemente genérica e ser demasiado específica para o caso de uso do controlo de congestionamento.

No caso de uso de controlo de congestionamento mencionado acima, Alice, a remetente, poderia criar 10 saídas e fazer hash dessas 10 saídas, e usar o digest resultante para criar um script de tapleaf que contenha COSHV. Alice também poderia usar as chaves públicas dos participantes para formar uma chave interna de Taproot que lhes permitiria colaborar na despesa do dinheiro sem revelar o caminho do script de Taproot.

Alice então dá a cada destinatário uma cópia de todos os 10 outputs para que cada um deles possa verificar a transação de configuração da Alice. Quando desejarem gastar o pagamento posteriormente, qualquer um deles pode criar uma transação com os outputs comprometidos.

Durante o processo, enquanto Alice cria e envia a transação de configuração, Alice pode enviar estas 10 cópias das saídas através de métodos de comunicação assíncrona existentes, como email ou drives na nuvem. Isto significa que os destinatários não precisam de estar online ou interagir uns com os outros.

Origem:https://bitcoinops.org/en/newsletters/2019/05/29/#proposed-transaction-output-commitments

Similar aos APOs, os endereços podem ser construídos com base em condições de gastos e podem ser "bloqueados" de diferentes maneiras, incluindo chaves extras, timelocks relativos ou fixos e outras lógicas para combiná-los.

Origem:https://twitter.com/OwenKemeys/status/1741575353716326835

Com base nisso, CTV propõe verificar se a transação gasta após o hash corresponde àquela definida, o que significa que os dados da transação são usados como chave para desbloquear o “bloqueio”.

Podemos estender o exemplo acima de 10 destinatários, onde um destinatário pode ainda fazer com que a sua chave de endereço seja uma TX assinada mas não transmitida, enviando para o próximo lote de destinatários, e assim por diante, formando uma estrutura de árvore como mostrado na figura abaixo. Alice pode construir uma alteração nos saldos das contas envolvendo vários utilizadores na cadeia usando apenas 1 UTXO de espaço de bloco.

Origem: https://twitter.com/OwenKemeys/status/1741575353716326835

E se uma das folhas for um canal de relâmpago, ou armazenamento a frio, ou algum outro caminho de pagamento? Então a árvore será expandida de uma árvore de pagamento multi-camadas unidimensional para uma árvore de pagamento multi-camadas multi-dimensional, e os cenários que podem ser suportados serão mais ricos e flexíveis.

Origem: https://twitter.com/OwenKemeys/status/1744181234417140076

Desde a sua proposta, o CTV passou por uma mudança de nome de COSHV em 2019, sendo designado BIP-119 em 2020, e o surgimento do Sapio, a linguagem de programação usada para criar o contrato de suporte ao CTV, e tem recebido muita discussão, atualizações e debate da comunidade sobre as suas opções de ativação em 2022 e 2023, e ainda é uma das propostas de atualização de soft fork mais discutidas na comunidade.

OP_CAT

OP_CAT, conforme descrito no parágrafo de abertura, é também uma proposta de atualização que está a receber muita atenção atualmente e implementa uma função que concatena dois elementos ou dois conjuntos de dados da pilha. Embora pareça simples, o OP_CAT é muito flexível e pode ser implementado em scripts de muitas maneiras.

O exemplo mais direto é a operação da Árvore de Merkle, que pode ser interpretada como dois elementos sendo concatenados e depois hashados. Atualmente, existem OP_SHA256 e outros códigos de operação de hash no script do Bitcoin, então se você pode concatenar dois elementos usando OP_CAT, você pode implementar a função de verificação da Árvore de Merkle no script, o que também fornece a capacidade de verificação do cliente leve até certo ponto.

Outra base para a implementação é a melhoria das assinaturas Schnorr: é possível definir a condição de assinatura de gasto de um script como uma concatenação da chave pública do usuário e de um nonce público; então, se o signatário quiser assinar outra transação para gastar os fundos em outro lugar, ele ou ela terá que usar o mesmo nonce, o que pode vazar a chave privada. Ou seja, OP_CAT alcança o comprometimento com o nonce e garante a validade da transação assinada.

Outras aplicações do OP_CAT incluem Bistream,assinaturas de árvore, assinaturas Lamport resistentes a quantum, cofres e muito mais.

O OP_CAT em si não é uma nova funcionalidade, pois existia nas primeiras versões do Bitcoin, masdesativadoem 2010 devido ao seu potencial para ser explorado por atacantes. Por exemplo, o uso repetido de OP_DUP e OP_CAT poderia facilmente fazer com que a pilha de nós completa explodisse ao processar tais scripts, como visto neste demonstração.

Mas o problema de explosão de pilha mencionado anteriormente não ocorrerá hoje em dia uma vez que o OP_CAT tenha sido reativado? Porque a proposta atual do OP_CAT envolve apenas a ativação no tapscript, que tem um limite de 520 bytes por elemento de pilha, não causará o problema de explosão de pilha anterior. Há também alguns desenvolvedores que pensam que Satoshi Nakamoto pode ter sido muito rigoroso ao desativar o OP_CAT completamente. No entanto, devido à flexibilidade do OP_CAT, é possível que existam alguns cenários de aplicação que possam levar a vulnerabilidades.

Portanto, combinando os cenários de aplicação e os riscos potenciais, OP_CAT tem recebido muita atenção recentemente e também teve uma Revisão de PR, e é atualmente uma das propostas de atualização mais quentes.

Conclusão

"A Auto-Regulação Traz Liberdade", como pode ser visto na introdução acima, os pactos podem ser implementados diretamente nos scripts do Bitcoin para qualificar gastos adicionais em transações, permitindo assim regras de transação semelhantes aos efeitos de contratos inteligentes. Esta abordagem de programação pode ser verificada de forma mais nativa no Bitcoin do que as abordagens off-chain, como BitVM, e também pode melhorar aplicações na main chain (controlo de congestão), aplicações off-chain (canal de estado) e outras novas direções de aplicação (staking slashing, etc.).

As técnicas de implementação dos pactos, se combinadas com algumas outras atualizações, poderiam desbloquear ainda mais o potencial de programabilidade. Por exemplo, a proposta recente para aritmética de 64 bits

em a reverpode ser ainda combinado com o proposto OP_TLUVou outras convenções que poderiam ser programadas com base no número de saídas de satoshi por uma transação.

No entanto, os pactos também podem levar a abusos ou vulnerabilidades não planeadas, por isso a comunidade também está cautelosa em relação a isso. Além disso, uma atualização dos pactos precisaria envolver uma atualização de fork suave das regras de consenso. Dadas as circunstâncias em torno da atualização do taproot, é provável que a atualização relacionada com os pactos também leve tempo a ser concluída.

Agradecimentos especiais

Obrigado Ajian, FishereBenpara revisão e sugestões!

Referências

• https://utxos.org/
• https://bitcoincovenants.com/
• Uma coleção de recursos relacionados a alianças: https://gist.github.com/RobinLinus/c96fb7c81430ec6dc92f048687bd3068
• https://anyprevout.xyz/
• BIP 345: Proposta OP_VAULT: https://www.btcstudy.org/2023/04/13/bitcoin-improvement-proposals-345-op-vault-commit-0b0674c546/
• https://fc17.ifca.ai/bitcoin/papers/bitcoin17-final28.pdf
• https://maltemoeser.de/paper/covenants.pdf
• https://bitcoinops.org/en/topics/op_cat/
• OP_CAT: https://github.com/bitcoin-inquisition/binana/blob/master/2024/BIN-2024-0001.md
• Truques de CAT e Schnorr: https://medium.com/blockstream/cat-and-schnorr-tricks-i-faf1b59bd298

Aviso Legal: Este material destina-se apenas a fins informativos gerais e não constitui, nem deve ser interpretado como, qualquer forma de aconselhamento de investimento, solicitação ou oferta de quaisquer investimentos, e a HashKey Capital não aceita qualquer responsabilidade em relação ao uso ou confiança em tais informações.

Mantenha-se atualizado com as últimas notícias da HashKey Capital -

Website — https://hashkey.capital/

Twitter — https://twitter.com/HashKey_Capital

LinkedIn —https://www.linkedin.com/company/hashkeycapital/

declaração:

1. Este artigo é reproduzido a partir de [médio], o direito de autor pertence ao autor original [Jeffrey HueHarper Li], se tiver alguma objeção à reimpressão, entre em contato com o Gate Learnequipa , e a equipa irá tratar disso o mais rápido possível de acordo com os procedimentos relevantes.

2. Aviso legal: As opiniões expressas neste artigo representam apenas as opiniões pessoais do autor e não constituem qualquer conselho de investimento.

3. Outras versões de idiomas do artigo são traduzidas pela equipe Gate Learn e não são mencionadas emGate.io, o artigo traduzido não pode ser reproduzido, distribuído ou plagiado.