Explicação detalhada das cláusulas restritivas: implementar a Programabilidade do Bitcoin
Recentemente, a comunidade Bitcoin gerou uma onda de discussões sobre a reativação de códigos de operação como o OP_CAT. O Taproot Wizard atraiu a atenção de muitos ao lançar o Quantum Cats NFT e afirmar que obteve o número BIP-420. Os apoiadores afirmam que a ativação do OP_CAT pode permitir "cláusulas restritivas", possibilitando contratos inteligentes ou programabilidade para Bitcoin.
Se você prestar atenção à expressão "termos de restrição" e fizer uma pequena pesquisa, descobrirá que este é outro grande buraco de coelho. Os desenvolvedores têm discutido por muitos anos, além do OP_CAT, tecnologias como OP_CTV, APO, OP_VAULT, entre outras, para implementar os termos de restrição.
Então, o que são exatamente as "cláusulas de restrição" do Bitcoin? Por que atraem tantos desenvolvedores para uma atenção e discussão contínuas durante vários anos? Que tipo de programabilidade pode ser realizada com o Bitcoin? Qual é o princípio de design por trás disso? Este artigo tenta fazer uma introdução e discussão abrangente.
O que são "cláusulas de limitação"
Limitações ( Covernants ) é um mecanismo que pode definir condições para transações futuras de Bitcoin.
O script atual do Bitcoin também inclui condições restritivas, como a necessidade de inserir uma assinatura válida ao gastar, ou enviar para um script compatível, etc. No entanto, desde que o usuário consiga desbloquear, ele pode gastar esse UTXO em qualquer lugar que desejar.
E as cláusulas de restrição são, com base na limitação de como desbloquear, fazer mais restrições, como limitar o gasto após o UTXO, ou seja, alcançar um efeito semelhante a "fundos destinados a fins específicos"; ou outras condições de entrada incluídas em uma transação.
De forma mais rigorosa, o script do Bitcoin atual também possui certas cláusulas de restrição, como os bloqueios de tempo baseados em códigos de operação, que são implementados através dos campos nLock ou nSequence da transação, para impor limites de tempo antes do gasto da transação, mas que também se limitam basicamente a restrições de tempo.
Então, por que os desenvolvedores e pesquisadores precisam projetar essas verificações de restrição? Porque os termos de restrição não são apenas para limitar por limitar, mas sim para estabelecer as regras de execução das transações. Assim, os usuários só podem executar transações de acordo com as regras previamente definidas, completando assim os processos de negócios planejados.
Portanto, é relativamente contra-intuitivo, mas isso pode desbloquear mais cenários de aplicação.
Cenários de Aplicação
Assegurar a penalização do Staking
Um exemplo muito intuitivo de cláusulas restritivas é a transação de slash no processo de staking do Bitcoin da Babylon.
O processo de staking de Bitcoin da Babylon é que os usuários enviem seus ativos BTC para um script especial na cadeia principal, onde as condições de gasto incluem duas tipos:
Situação normal: Após um certo tempo, o usuário pode desbloquear com sua própria assinatura, completando assim o processo de unstake.
Situações anómalas: Se um usuário tiver comportamentos maliciosos, como dupla assinatura, em uma cadeia PoS de segurança alugada pela Babylon, então, através de EOTS( assinaturas descartáveis extraíveis, uma única assinatura extraível) pode desbloquear essa parte dos ativos, e um dos papéis de execução na rede forçará o envio de uma parte dos ativos para o endereço de queima( slash).
Note que aqui o "envio forçado" significa que, mesmo que este UTXO possa ser desbloqueado, o ativo não pode ser enviado livremente para qualquer outro lugar, apenas pode ser queimado. Assim, garante-se que usuários mal-intencionados não consigam usar a assinatura que já conhecem para transferir o ativo de volta para si mesmos, escapando da punição.
Esta funcionalidade, se implementada após a realização de cláusulas restritivas como o OP_CTV, pode adicionar opcodes como o OP_CTV no ramo de "situações excepcionais" do script de staking para implementar restrições.
E antes da ativação do OP_CTV, a Babylon precisa simular a execução dos efeitos das cláusulas restritivas através de métodos alternativos, executados em conjunto pelos usuários + comitê.
Controle de Congestionamento
Em geral, congestionamento refere-se ao fato de que, quando a taxa de transação da rede Bitcoin é muito alta, há um acúmulo significativo de transações na pool de transações aguardando para ser processadas. Portanto, se os usuários desejam confirmar suas transações rapidamente, precisam aumentar a taxa de transação.
E, neste momento, se um usuário precisar enviar várias transações para vários destinatários, terá que aumentar a taxa de transação, assumindo um custo relativamente alto. Ao mesmo tempo, isso também irá elevar ainda mais a taxa de transação de toda a rede.
Se houver cláusulas restritivas, uma solução é que o remetente pode primeiro comprometer-se com uma transação de envio em lote. Este compromisso pode fazer com que todos os destinatários acreditem que a transação final será realizada, podendo esperar até que as taxas de transação estejam mais baixas para enviar a transação específica.
Quando a demanda por espaço em bloco é muito alta, realizar transações torna-se muito caro. Ao usar OP_CHECKTEMPLATEVERIFY, processadores de pagamento em grande escala podem agregar todos os seus pagamentos em uma única transação O(1) para confirmação. Depois, após algum tempo, quando a demanda por espaço em bloco diminui, os pagamentos podem ser expandidos a partir desse UTXO.
Este cenário é um caso de aplicação bastante típico da cláusula restritiva OP_CTV.
Cofragem
O cofre (vault) é um tipo de cenário de aplicação amplamente discutido em aplicações de Bitcoin, especialmente na área de termos restritivos. Como as operações diárias inevitavelmente precisam equilibrar a custódia de fundos e a necessidade de utilização de fundos, as pessoas esperam que exista um tipo de aplicação de cofre que possa garantir a segurança dos fundos, mesmo que a conta seja hackeada ( e a chave privada ) seja divulgada, limitando assim o uso dos fundos.
Com base na tecnologia para implementar cláusulas de restrição, aplicações do tipo custódia podem ser construídas com relativa facilidade.
Usando o design do OP_VAULT como exemplo: ao gastar os fundos no cofre, é necessário enviar uma transação para a blockchain. Esta transação indica a intenção de gastar o cofre, ou seja, "trigger", e estabelece as condições:
Se tudo correr bem, a segunda transação será a transação de retirada final. Após esperar N blocos, os fundos podem ser gastos em qualquer lugar.
Se descobrir que a transação foi roubada ( ou que foi forçada por um "ataque de chave inglesa" ), antes do envio da transação de retirada em N blocos, pode imediatamente enviar para outro endereço seguro ( para um armazenamento mais seguro para o usuário ).
É importante notar que, na ausência de cláusulas restritivas, também é possível construir uma aplicação de custódia. Uma abordagem viável é preparar a assinatura para gastos futuros com a chave privada e, em seguida, destruir essa chave privada. No entanto, ainda existem muitas restrições, como a necessidade de garantir que a chave privada foi destruída (, semelhante ao processo de configuração confiável em provas de conhecimento zero ), o montante e as taxas serem determinados antecipadamente (, devido à necessidade de pré-assinatura ), o que resulta em falta de flexibilidade, entre outros.
um canal de estado mais robusto e flexível
Geralmente, pode-se considerar que os canais de estado, incluindo a Lightning Network, possuem uma segurança quase idêntica à da cadeia principal (, desde que os nós possam observar o estado mais recente e publicar normalmente o estado mais recente na cadeia ). No entanto, com a introdução de cláusulas restritivas, algumas novas ideias de design de canais de estado podem ser mais robustas ou flexíveis em cima da Lightning Network. Entre as mais conhecidas estão Eltoo, Ark, entre outras.
Eltoo (, também conhecido como LN-Symmetry), é um dos exemplos mais típicos. Esta solução técnica tira partido da homofonia de "L2", propondo uma camada de execução para a rede Lightning, que permite que qualquer estado de canal subsequente substitua o estado anterior, sem necessidade de um mecanismo de penalização, evitando assim também a necessidade de nós da rede Lightning manterem múltiplos estados anteriores para impedir comportamentos maliciosos. Para alcançar o efeito mencionado, o Eltoo propôs o método de assinatura SIGHASH_NOINPUT, ou seja, APO(BIP-118).
E o Ark visa reduzir a dificuldade de liquidez de entrada e gestão de canais na Lightning Network. É um protocolo na forma de joinpool, onde vários usuários podem aceitar um prestador de serviços como contraparte por um determinado período, realizando 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 cláusulas restritivas, 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.
Visão Geral dos Termos de Restrição
A partir das aplicações acima, pode-se ver que as cláusulas restritivas se assemelham mais a um efeito do que a uma tecnologia específica, portanto existem muitas maneiras técnicas de implementá-las. Se forem classificadas, podem incluir:
Tipo: Geral, Específico
Método de implementação: baseado em Opcode, baseado em assinatura
Recursão: recursão, não recursão
E entre eles, recursão refere-se a: a implementação de algumas cláusulas restritivas pode também limitar a saída da próxima transação para restringir a saída da transação seguinte, permitindo que as limitações adicionadas superem uma única transação, alcançando uma maior profundidade de transação.
Alguns designs de cláusulas restritivas comuns incluem:
OP_CTV: Tipo geral, baseado em Opcode, não recursivo
OP_VAULT: tipo dedicado, baseado em Opcode, não recursivo
APO: tipo genérico, baseado em assinatura, não recursivo
OP_CAT: Tipo genérico, baseado em Opcode, recursivo*
OP_CSFS: Tipo genérico, baseado em assinatura, recursivo
*se combinado com OP_CAT
Design dos termos de restrição
A partir da introdução anterior, pode-se ver que o script do Bitcoin atualmente limita as condições de desbloqueio, mas não limita como esse UTXO pode ser gasto posteriormente. Para implementar cláusulas restritivas, devemos pensar ao contrário: por que o script do Bitcoin atualmente não consegue implementar cláusulas restritivas?
A razão principal está no fato de que o script do Bitcoin atualmente não consegue ler o conteúdo da própria transação, ou seja, a "introspecção" (introspection) da transação.
Se conseguirmos realizar a introspecção das transações - verificar qualquer conteúdo da transação (, incluindo a saída ), então poderemos implementar cláusulas restritivas.
Assim, o conceito de design das cláusulas restritivas gira principalmente em torno de como realizar a introspecção.
Baseado em código de operação vs Baseado em assinatura
A ideia mais simples e direta é adicionar um ou mais códigos de operação (, ou seja, um código de operação + vários parâmetros, ou vários códigos de operação ) com diferentes funcionalidades, para ler diretamente o conteúdo da transação. Esta é precisamente 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 sim utilizar o hash do conteúdo da transação - se esse hash já foi assinado, então basta modificar, por exemplo, o OP_CHECKSIG no script para implementar a verificação dessa assinatura, permitindo assim a introspecção da transação e a imposição de cláusulas. Essa abordagem é baseada no design de assinatura. Inclui principalmente APO e OP_CSFS.
APO
SIGHASH_ANYPREVOUT(APO) é um tipo proposto de assinatura de Bitcoin. A forma mais simples de assinar é comprometer-se com a entrada e saída da transação, mas o Bitcoin tem uma forma mais flexível, ou seja, SIGHASH, que permite comprometer-se seletivamente com a entrada ou saída de uma transação.
E o SIGHASH do APO assina apenas a saída, e não a parte da entrada. Isso significa que, após assinar a transação com o método APO, ela pode ser
Esta página pode conter conteúdo de terceiros, que é fornecido apenas para fins informativos (não para representações/garantias) e não deve ser considerada como um endosso de suas opiniões pela Gate nem como aconselhamento financeiro ou profissional. Consulte a Isenção de responsabilidade para obter detalhes.
Análise detalhada das cláusulas restritivas do Bitcoin: Abrindo uma nova era de Programabilidade
Explicação detalhada das cláusulas restritivas: implementar a Programabilidade do Bitcoin
Recentemente, a comunidade Bitcoin gerou uma onda de discussões sobre a reativação de códigos de operação como o OP_CAT. O Taproot Wizard atraiu a atenção de muitos ao lançar o Quantum Cats NFT e afirmar que obteve o número BIP-420. Os apoiadores afirmam que a ativação do OP_CAT pode permitir "cláusulas restritivas", possibilitando contratos inteligentes ou programabilidade para Bitcoin.
Se você prestar atenção à expressão "termos de restrição" e fizer uma pequena pesquisa, descobrirá que este é outro grande buraco de coelho. Os desenvolvedores têm discutido por muitos anos, além do OP_CAT, tecnologias como OP_CTV, APO, OP_VAULT, entre outras, para implementar os termos de restrição.
Então, o que são exatamente as "cláusulas de restrição" do Bitcoin? Por que atraem tantos desenvolvedores para uma atenção e discussão contínuas durante vários anos? Que tipo de programabilidade pode ser realizada com o Bitcoin? Qual é o princípio de design por trás disso? Este artigo tenta fazer uma introdução e discussão abrangente.
O que são "cláusulas de limitação"
Limitações ( Covernants ) é um mecanismo que pode definir condições para transações futuras de Bitcoin.
O script atual do Bitcoin também inclui condições restritivas, como a necessidade de inserir uma assinatura válida ao gastar, ou enviar para um script compatível, etc. No entanto, desde que o usuário consiga desbloquear, ele pode gastar esse UTXO em qualquer lugar que desejar.
E as cláusulas de restrição são, com base na limitação de como desbloquear, fazer mais restrições, como limitar o gasto após o UTXO, ou seja, alcançar um efeito semelhante a "fundos destinados a fins específicos"; ou outras condições de entrada incluídas em uma transação.
De forma mais rigorosa, o script do Bitcoin atual também possui certas cláusulas de restrição, como os bloqueios de tempo baseados em códigos de operação, que são implementados através dos campos nLock ou nSequence da transação, para impor limites de tempo antes do gasto da transação, mas que também se limitam basicamente a restrições de tempo.
Então, por que os desenvolvedores e pesquisadores precisam projetar essas verificações de restrição? Porque os termos de restrição não são apenas para limitar por limitar, mas sim para estabelecer as regras de execução das transações. Assim, os usuários só podem executar transações de acordo com as regras previamente definidas, completando assim os processos de negócios planejados.
Portanto, é relativamente contra-intuitivo, mas isso pode desbloquear mais cenários de aplicação.
Cenários de Aplicação
Assegurar a penalização do Staking
Um exemplo muito intuitivo de cláusulas restritivas é a transação de slash no processo de staking do Bitcoin da Babylon.
O processo de staking de Bitcoin da Babylon é que os usuários enviem seus ativos BTC para um script especial na cadeia principal, onde as condições de gasto incluem duas tipos:
Note que aqui o "envio forçado" significa que, mesmo que este UTXO possa ser desbloqueado, o ativo não pode ser enviado livremente para qualquer outro lugar, apenas pode ser queimado. Assim, garante-se que usuários mal-intencionados não consigam usar a assinatura que já conhecem para transferir o ativo de volta para si mesmos, escapando da punição.
Esta funcionalidade, se implementada após a realização de cláusulas restritivas como o OP_CTV, pode adicionar opcodes como o OP_CTV no ramo de "situações excepcionais" do script de staking para implementar restrições.
E antes da ativação do OP_CTV, a Babylon precisa simular a execução dos efeitos das cláusulas restritivas através de métodos alternativos, executados em conjunto pelos usuários + comitê.
Controle de Congestionamento
Em geral, congestionamento refere-se ao fato de que, quando a taxa de transação da rede Bitcoin é muito alta, há um acúmulo significativo de transações na pool de transações aguardando para ser processadas. Portanto, se os usuários desejam confirmar suas transações rapidamente, precisam aumentar a taxa de transação.
E, neste momento, se um usuário precisar enviar várias transações para vários destinatários, terá que aumentar a taxa de transação, assumindo um custo relativamente alto. Ao mesmo tempo, isso também irá elevar ainda mais a taxa de transação de toda a rede.
Se houver cláusulas restritivas, uma solução é que o remetente pode primeiro comprometer-se com uma transação de envio em lote. Este compromisso pode fazer com que todos os destinatários acreditem que a transação final será realizada, podendo esperar até que as taxas de transação estejam mais baixas para enviar a transação específica.
Quando a demanda por espaço em bloco é muito alta, realizar transações torna-se muito caro. Ao usar OP_CHECKTEMPLATEVERIFY, processadores de pagamento em grande escala podem agregar todos os seus pagamentos em uma única transação O(1) para confirmação. Depois, após algum tempo, quando a demanda por espaço em bloco diminui, os pagamentos podem ser expandidos a partir desse UTXO.
Este cenário é um caso de aplicação bastante típico da cláusula restritiva OP_CTV.
Cofragem
O cofre (vault) é um tipo de cenário de aplicação amplamente discutido em aplicações de Bitcoin, especialmente na área de termos restritivos. Como as operações diárias inevitavelmente precisam equilibrar a custódia de fundos e a necessidade de utilização de fundos, as pessoas esperam que exista um tipo de aplicação de cofre que possa garantir a segurança dos fundos, mesmo que a conta seja hackeada ( e a chave privada ) seja divulgada, limitando assim o uso dos fundos.
Com base na tecnologia para implementar cláusulas de restrição, aplicações do tipo custódia podem ser construídas com relativa facilidade.
Usando o design do OP_VAULT como exemplo: ao gastar os fundos no cofre, é necessário enviar uma transação para a blockchain. Esta transação indica a intenção de gastar o cofre, ou seja, "trigger", e estabelece as condições:
É importante notar que, na ausência de cláusulas restritivas, também é possível construir uma aplicação de custódia. Uma abordagem viável é preparar a assinatura para gastos futuros com a chave privada e, em seguida, destruir essa chave privada. No entanto, ainda existem muitas restrições, como a necessidade de garantir que a chave privada foi destruída (, semelhante ao processo de configuração confiável em provas de conhecimento zero ), o montante e as taxas serem determinados antecipadamente (, devido à necessidade de pré-assinatura ), o que resulta em falta de flexibilidade, entre outros.
um canal de estado mais robusto e flexível
Geralmente, pode-se considerar que os canais de estado, incluindo a Lightning Network, possuem uma segurança quase idêntica à da cadeia principal (, desde que os nós possam observar o estado mais recente e publicar normalmente o estado mais recente na cadeia ). No entanto, com a introdução de cláusulas restritivas, algumas novas ideias de design de canais de estado podem ser mais robustas ou flexíveis em cima da Lightning Network. Entre as mais conhecidas estão Eltoo, Ark, entre outras.
Eltoo (, também conhecido como LN-Symmetry), é um dos exemplos mais típicos. Esta solução técnica tira partido da homofonia de "L2", propondo uma camada de execução para a rede Lightning, que permite que qualquer estado de canal subsequente substitua o estado anterior, sem necessidade de um mecanismo de penalização, evitando assim também a necessidade de nós da rede Lightning manterem múltiplos estados anteriores para impedir comportamentos maliciosos. Para alcançar o efeito mencionado, o Eltoo propôs o método de assinatura SIGHASH_NOINPUT, ou seja, APO(BIP-118).
E o Ark visa reduzir a dificuldade de liquidez de entrada e gestão de canais na Lightning Network. É um protocolo na forma de joinpool, onde vários usuários podem aceitar um prestador de serviços como contraparte por um determinado período, realizando 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 cláusulas restritivas, 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.
Visão Geral dos Termos de Restrição
A partir das aplicações acima, pode-se ver que as cláusulas restritivas se assemelham mais a um efeito do que a uma tecnologia específica, portanto existem muitas maneiras técnicas de implementá-las. Se forem classificadas, podem incluir:
E entre eles, recursão refere-se a: a implementação de algumas cláusulas restritivas pode também limitar a saída da próxima transação para restringir a saída da transação seguinte, permitindo que as limitações adicionadas superem uma única transação, alcançando uma maior profundidade de transação.
Alguns designs de cláusulas restritivas comuns incluem:
*se combinado com OP_CAT
Design dos termos de restrição
A partir da introdução anterior, pode-se ver que o script do Bitcoin atualmente limita as condições de desbloqueio, mas não limita como esse UTXO pode ser gasto posteriormente. Para implementar cláusulas restritivas, devemos pensar ao contrário: por que o script do Bitcoin atualmente não consegue implementar cláusulas restritivas?
A razão principal está no fato de que o script do Bitcoin atualmente não consegue ler o conteúdo da própria transação, ou seja, a "introspecção" (introspection) da transação.
Se conseguirmos realizar a introspecção das transações - verificar qualquer conteúdo da transação (, incluindo a saída ), então poderemos implementar cláusulas restritivas.
Assim, o conceito de design das cláusulas restritivas gira principalmente em torno de como realizar a introspecção.
Baseado em código de operação vs Baseado em assinatura
A ideia mais simples e direta é adicionar um ou mais códigos de operação (, ou seja, um código de operação + vários parâmetros, ou vários códigos de operação ) com diferentes funcionalidades, para ler diretamente o conteúdo da transação. Esta é precisamente 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 sim utilizar o hash do conteúdo da transação - se esse hash já foi assinado, então basta modificar, por exemplo, o OP_CHECKSIG no script para implementar a verificação dessa assinatura, permitindo assim a introspecção da transação e a imposição de cláusulas. Essa abordagem é baseada no design de assinatura. Inclui principalmente APO e OP_CSFS.
APO
SIGHASH_ANYPREVOUT(APO) é um tipo proposto de assinatura de Bitcoin. A forma mais simples de assinar é comprometer-se com a entrada e saída da transação, mas o Bitcoin tem uma forma mais flexível, ou seja, SIGHASH, que permite comprometer-se seletivamente com a entrada ou saída de uma transação.
E o SIGHASH do APO assina apenas a saída, e não a parte da entrada. Isso significa que, após assinar a transação com o método APO, ela pode ser