Bitcoin restrições: nova direção para a Programabilidade

A comunidade Bitcoin tem discutido intensamente a reativação de operações como o OP_CAT. O Taproot Wizard atraiu grande atenção ao lançar os Quantum Cats NFT e reivindicar o número BIP-420. Os apoiadores afirmam que a ativação do OP_CAT pode permitir "cláusulas restritivas", trazendo contratos inteligentes e programabilidade para o Bitcoin.

"cláusulas restritivas"(covenants) este conceito gerou anos de discussão entre desenvolvedores. Além de OP_CAT, existem várias soluções técnicas para implementar cláusulas restritivas, como OP_CTV, APO, OP_VAULT, entre outras. Então, o que são as "cláusulas restritivas" do Bitcoin? Por que elas conseguem gerar tanta atenção ampla e duradoura? Que tipo de programabilidade elas podem trazer ao Bitcoin? Qual é o princípio de design por trás disso? Este artigo apresentará uma visão geral e discussão sobre essas questões.

O que são "cláusulas restritivas"

"Cláusulas Restritivas" ( covenants ) são um mecanismo que pode definir condições para futuras transações de Bitcoin. Os scripts atuais de Bitcoin já incluem algumas condições restritivas, como a necessidade de uma assinatura válida, a apresentação de scripts que atendam aos requisitos, entre outros. Mas, desde que o usuário consiga desbloquear, pode gastar UTXO em qualquer lugar.

E as cláusulas restritivas aumentaram mais limitações com base nisso, como restringir o destino da despesa subsequente do UTXO, alcançando o efeito de "fundos específicos para fins específicos"; ou restringir as condições de outros inputs em uma transação, entre outros.

Mais precisamente, o script do Bitcoin atual também possui certas funcionalidades de cláusulas de restrição, como o bloqueio temporal baseado em códigos de operação. Ao verificar os campos nLock ou nSequence da transação, é possível implementar uma limitação de tempo antes do gasto da transação. Mas atualmente, isso está principalmente limitado a restrições de tempo.

Os desenvolvedores projetaram essas verificações de limite não apenas para restringir, mas também para definir as regras de execução das transações. Os usuários só podem executar transações de acordo com as regras pré-definidas, completando assim o fluxo de negócios planejado.

Assim, as cláusulas restritivas, de forma contra-intuitiva, podem desbloquear mais cenários de aplicação.

Cenários de Aplicação

Assegure a penalização do Staking

Um exemplo intuitivo de cláusulas de restrição é a transação de slash da Babylon em staking de Bitcoin.

O processo de staking de Bitcoin da Babylon é quando os usuários enviam ativos BTC para um script especial na cadeia principal, e as condições de gasto incluem dois tipos:

1. Fim normal: Após um certo período de tempo, o usuário pode desbloquear com sua própria assinatura, completando o processo de unstake.

2. Fim da penalização: Se o utilizador cometer ações maliciosas como dupla assinatura na cadeia PoS de segurança de Babylon, então através do EOTS( pode-se extrair uma assinatura única ) que pode desbloquear ativos, e os papéis de execução na rede enviarão forçosamente parte dos ativos para o endereço de queima (slash).

Aqui, "envio forçado" significa que, mesmo que o UTXO possa ser desbloqueado, o ativo não pode ser enviado livremente para outro lugar, apenas pode ser queimado. Isso garante que usuários mal-intencionados não consigam usar uma assinatura conhecida para devolver o ativo a si mesmos, escapando da punição.

Após a implementação das cláusulas restritivas como OP_CTV, podem ser adicionados códigos de operação relevantes na ramificação de "fim da penalização" do script de staking para implementar as restrições.

Antes da ativação do OP_CTV, a Babylon precisa simular a execução dos efeitos de imposição das cláusulas restritivas através de um método alternativo executado conjuntamente pelos usuários e pelo comitê.

Controle de Congestionamento

Quando a rede está congestionada, uma grande quantidade de transações pendentes se acumula na pool de transações, e os usuários precisam aumentar a taxa de transação para obter uma confirmação rápida. Se o usuário tiver que enviar várias transações para vários destinatários, terá que arcar com custos mais elevados, aumentando ainda mais a taxa de transação de toda a rede.

Com a cláusula de limitação, o remetente pode primeiro comprometer-se com uma transação de envio em lote. Este compromisso faz com que todos os destinatários acreditem que a transação final será executada, podendo esperar pela redução das taxas de transação antes de enviar a transação específica.

Quando a demanda por espaço em bloco é alta, as transações se tornam caras. Usando OP_CHECKTEMPLATEVERIFY, os processadores de pagamento em grande volume podem agregar todos os pagamentos em uma única transação O(1) para confirmação. Depois, quando a demanda por espaço em bloco diminui, os pagamentos podem ser expandidos a partir desse UTXO.

Este é um dos casos de aplicação típicos propostos pela cláusula de limitação OP_CTV.

Cofragem

O vault( é um cenário amplamente discutido na aplicação do Bitcoin, especialmente na área de termos restritivos. As operações diárias precisam equilibrar a custódia de fundos e as necessidades de uso, e as pessoas desejam uma aplicação de cofre que garanta a segurança dos fundos, mesmo que a conta seja hackeada) e a chave privada seja divulgada(, podendo assim limitar o uso dos fundos.

Com base na tecnologia de cláusulas restritivas, é relativamente fácil construir aplicações de custódia.

Usando o exemplo do plano OP_VAULT: ao gastar fundos do cofre, é necessário primeiro enviar uma transação para a blockchain para indicar a intenção )"trigger"(, e definir as condições:

• Situação normal: a segunda transação é a transação de retirada final. Após esperar N blocos, os fundos podem ser gastos adicionalmente para qualquer endereço.

• Situações anormais: Se descobrir que é uma transação roubada ) ou for coagido (, pode imediatamente enviar os fundos para um endereço mais seguro antes de a transação de retirada ser enviada em N blocos.

É importante notar que, mesmo na ausência de cláusulas restritivas, é possível construir aplicações de custódia. Uma maneira é preparar a assinatura para gastos futuros com a chave privada e, em seguida, destruir a chave privada. No entanto, esse método ainda tem limitações, como a necessidade de garantir que a chave privada foi destruída, os montantes e as taxas precisam ser determinados com antecedência, entre outros, faltando flexibilidade.

![Detalhes sobre Covenants: como alcançar a Programabilidade do Bitcoin?])https://img-cdn.gateio.im/webp-social/moments-bf8295d231f632f2f6303d826e3e450b.webp(

) um canal de estado mais robusto e flexível

Os canais de estado ### incluem a rede Lightning (, onde, sob a condição de que os nós possam observar o estado mais recente e publicar normalmente o estado mais recente na cadeia, pode-se considerar que possuem uma segurança quase idêntica à da cadeia principal. Com a adição de cláusulas restritivas, alguns novos designs de canais de estado podem ser mais robustos ou flexíveis, sendo os mais conhecidos Eltoo, Ark, entre outros.

Eltoo), também conhecido como LN-Symmetry(, é um exemplo típico. Ele propõe uma camada de execução para a Lightning Network, permitindo que qualquer estado de canal posterior substitua o estado anterior, sem necessidade de mecanismo de penalização, evitando assim que os nós da Lightning Network precisem armazenar múltiplos estados anteriores para prevenir comportamentos maliciosos do oponente. Eltoo propõe o método de assinatura SIGHASH_NOINPUT, ou seja, APO)BIP-118( para alcançar esse efeito.

Ark visa reduzir a dificuldade de liquidez de entrada e gestão de canais na Lightning Network. É um protocolo na forma de joinpool, onde múltiplos usuários podem, por um determinado período, aceitar um prestador de serviços como contraparte para realizar transações de UTXO)vUTXO( fora da cadeia, mas compartilhando um UTXO na cadeia para reduzir custos. Semelhante a um cofre, o Ark também pode ser implementado na atual rede Bitcoin; no entanto, após a introdução de termos restritivos, o Ark pode reduzir a quantidade de interações necessárias com base em modelos de transação, permitindo uma saída unilateral mais descentralizada.

![Explicação detalhada sobre Covenants: como alcançar a Programabilidade do Bitcoin?])https://img-cdn.gateio.im/webp-social/moments-1344dbfaff294b02ebc0017e31d2a81d.webp(

Visão Geral das Condições Restritivas

A partir das aplicações acima, podemos ver que as cláusulas de limitação parecem mais um efeito do que uma tecnologia específica, portanto, existem várias formas de implementação. Podem ser classificadas a partir das seguintes dimensões:

• Tipo: Geral, Específico
• Modo de implementação: baseado em código de operação, baseado em assinatura
• Recursividade: recursão, não recursão

Neste contexto, a recursão refere-se à implementação de algumas cláusulas restritivas que podem limitar a próxima saída para restringir a saída seguinte, implementando limitações que se estendem a múltiplas transações.

Os principais designs de cláusulas restritivas incluem:

• OP_CTV: tipo genérico, baseado em código de operação, não recursivo
• APO: tipo genérico, baseado em assinatura, não recursivo
• OP_VAULT: tipo especializado, baseado em código de operação, não recursivo
• OP_CAT: Tipo genérico, baseado em código de operação, recursivo ) se combinado com OP_CAT (

![Explicação detalhada sobre Covenants: como implementar a Programabilidade do Bitcoin?])https://img-cdn.gateio.im/webp-social/moments-a077d9a30293ef68ccb8482bfc57aeea.webp(

Design das cláusulas restritivas

Os scripts de Bitcoin atuais limitam principalmente as condições de desbloqueio, sem restringir como os UTXO podem ser gastos posteriormente. Para implementar cláusulas restritivas, é necessário refletir sobre por que os scripts atuais não conseguem realizar essa funcionalidade.

O principal motivo é que atualmente o script do Bitcoin não consegue ler o conteúdo da própria transação, ou seja, a "introspecção" ).

Se for possível realizar a introspecção das transações—verificar qualquer conteúdo da transação ( incluindo a saída ), os termos de restrição podem ser implementados.

Assim, o design das cláusulas restritivas gira principalmente em torno de como implementar a introspecção.

( baseado em código de operação vs baseado em assinatura

A abordagem mais direta é adicionar um ou mais códigos de operação ) um código de operação + vários parâmetros, ou vários códigos de operação de funcionalidades diferentes ###, para ler diretamente o conteúdo da transação. Esta é a abordagem baseada em códigos de operação.

Outra abordagem é não ler e verificar diretamente o conteúdo da transação no script, mas usar o hash do conteúdo da transação - se este hash já foi assinado, então basta modificar no script como OP_CHECKSIG, entre outros, para verificar essa assinatura, o que permite realizar a introspecção da transação e impor cláusulas de forma indireta. Este é um modo de design baseado em assinatura, que inclui principalmente APO e OP_CSFS.

( APO

SIGHASH_ANYPREVOUT)APO### é um método proposto de assinatura de Bitcoin. A maneira mais simples de assinar é comprometer-se com todas as entradas e saídas da transação, mas o Bitcoin tem uma abordagem mais flexível, que é o SIGHASH, que permite comprometer-se seletivamente com as entradas ou saídas da transação.

O SIGHASH do APO assina apenas a saída, não a parte de entrada. Isso significa que uma transação assinada com o método APO pode ser posteriormente anexada a qualquer UTXO que atenda às condições.

Esta flexibilidade é a base teórica para a implementação das cláusulas de limitação do APO:

• Pode criar uma ou mais transações antecipadamente
• Construir uma chave pública que só pode resultar numa assinatura a partir destas informações de transação.
• Assim, qualquer ativo enviado para esse endereço de chave pública só pode ser gasto através de transações criadas previamente.

É importante notar que, uma vez que esta chave pública não tem uma chave privada correspondente, pode-se garantir que esses ativos só podem ser gastos através de transações pré-criadas. Podemos especificar o destino dos ativos nessas transações pré-criadas, implementando assim as cláusulas de restrição.

Podemos entender comparando os contratos inteligentes do Ethereum: através dos contratos inteligentes, o que podemos realizar também é que somente sob certas condições podemos retirar fundos do endereço do contrato, e não simplesmente gastar à vontade com a assinatura de um EOA. Sob esse ponto de vista, o Bitcoin pode alcançar esse efeito através da melhoria do mecanismo de assinatura.

Mas o problema no processo acima é que existe uma dependência cíclica durante o cálculo, pois é necessário conhecer o conteúdo de entrada para pré-assinar e criar a transação.

A importância da implementação desse método de assinatura com APO e SIGHASH_NOINPUT reside na capacidade de resolver esse problema de dependência circular, onde durante o cálculo só é necessário conhecer todas as saídas da transação ( especificada por ).

( OP_CTV

OP_CHECKTEMPLATEVERIFY)CTV###, ou BIP-119, utiliza um opcode melhorado.