Os "Pactos" 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 de 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 apresentadas e como elas melhoram a programabilidade e as 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 possíveis disputas na comunidade.
Co-escrito por Jeffrey HueHarper Li
Houve recentemente uma onda de discussão na comunidade Bitcoin sobre a reativação de opcodes como OP_CAT, e o Taproot Wizard atraiu muita atenção ao lançar o NFT dos Quantum Cats, alegando ter recebido a atribuição BIP-420. Os defensores afirmam que a ativação do OP_CAT irá realizar "pactos", e assim trazer contratos inteligentes ou programabilidade ao Bitcoin.
Se você notar a palavra “covenants” e fizer uma pequena pesquisa, verá que este é mais um grande buraco de coelho. Os desenvolvedores vêm falando há anos sobre tecnologias que implementam covenants, como OP_CTV, APO, OP_VAULT e mais, além de OP_CAT.
Mais precisamente, os scripts atuais do Bitcoin também possuem alguns tipos de pactos, como bloqueios de tempo baseados em opcode, que são implementados por meio da introspecção do campo nLock ou nSequence da transação para limitar a quantidade de tempo antes que a transação possa ser gasta, mas ainda estão apenas limitados a restrições de tempo.
Então, o que exatamente são os 'pactos' do Bitcoin? Por que tem atraído tanta atenção e discussão dos desenvolvedores há 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.
Pacto é um mecanismo que pode definir condições para 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 em conformidade ao gastar. Desde que o usuário consiga desbloqueá-lo, ele pode gastar esse UTXO onde desejar.
O Pacto é impor mais restrições além dessa limitação sobre como desbloquear, como limitar os gastos de UTXO após ser gasto, que é para alcançar um efeito semelhante ao de reserva, ou outras condições de entrada inseridas em uma transação, etc.
Então, por que os desenvolvedores e pesquisadores projetam essas verificações de restrição? Isso ocorre porque os covenants não são apenas restrições por nada, mas sim definir as regras para a execução do comércio. Dessa forma, o usuário só pode executar transações de acordo com as regras pré-definidas, completando assim o processo de negócios pretendido.
Então, de maneira contra-intuitiva, isso traz mais cenários de aplicação.
Um dos exemplos mais intuitivos de uma aliança é a transação de corte de Babilônia no processo de staking do Bitcoin.
O processo de staking de Bitcoin da Babilônia envolve os usuários enviando seu BTC para um script especial na main chain com duas condições de gasto:
Origem: Bitcoin Staking: Desbloqueando 21M Bitcoins para Segurar a Economia de Prova de Participação
Observe 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 consiga transferir 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 códigos de operação ao "fim ruim" do script de staking.
Antes que o OP_CTV seja ativado, Babilônia precisará de uma solução alternativa para emular o efeito de fazer cumprir os pactos, tendo o usuário + comitê trabalhando juntos.
Em termos gerais, a congestão ocorre quando a taxa está alta no Bitcoin com um número relativamente grande de transações acumuladas na pool de transações aguardando para serem empacotadas, então se um usuário deseja confirmar uma transação rapidamente, ele ou ela precisa aumentar a taxa.
Nesse ponto, se um usuário tiver que enviar várias transações para vários endereços, ele terá que aumentar suas taxas e incorrer em custos mais altos. Consequentemente, isso aumentará ainda mais a taxa de transação de toda a rede.
Se houver um pacto, então existe 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 esperar até que a taxa esteja baixa antes de enviar a transação específica.
Conforme mostrado abaixo, quando a demanda por espaço de bloco é alta, torna-se muito caro conduzir transações. Ao usar OP_CHECKTEMPLATEVERIFY, um processador de pagamento de alto volume pode agregar todos os seus pagamentos em uma única transação O(1) para confirmação. Então, 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
Origem: https://utxos.org/usos/escalabilidade/
Este cenário é um dos casos de uso mais típicos apresentados por esta restrição OP_CTV. Muitos outros casos de uso podem ser encontrados em https://utxos.org/uses.Além do controle de congestionamento mencionado acima, a página lista Apostas Soft Fork, opções descentralizadas, Drivechains, Canais de lote, Canais não interativos, Pools de mineração sem coordenação de confiança, Vaults, Contratos mais seguros com Tempo Fechado Hashed (HTLCS) Limites, e mais.
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 inevitavelmente envolvem equilibrar a necessidade de manter os fundos seguros com a necessidade de usá-los, gostaríamos de ter um cofre que possa manter os fundos seguros, ou até mesmo restringir 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.
Tomemos o esquema de design do OP_VAULT como exemplo: ao gastar fundos no cofre, uma transação precisa ser enviada para a cadeia primeiro. Essa transação indica a intenção de gastar o cofre, que é um "gatilho", e condições são definidas nela:
Processo de OP_VAULT, fonte: BIP-345
Note que também é possível construir um cofre sem pactos, e uma maneira possível de fazer isso é usar uma chave privada para preparar uma assinatura para gastos posteriores e, em seguida, destruir essa chave privada. No entanto, ainda existem mais limitações, como a necessidade de garantir que a chave privada tenha sido destruída (similar ao processo de configuração confiável em provas de conhecimento zero) e a falta de flexibilidade na determinação do valor e da taxa antecipadamente (por causa da pré-assinatura).
Cofres pré-calculados e OP_VAULT, fonte: BIP-345
Geralmente, pode-se assumir que os canais de estado, incluindo a Lightning Network, têm praticamente a mesma segurança que a cadeia principal (em termos de garantir que os nós possam observar o estado mais recente e possam postar corretamente o estado mais recente na cadeia). No entanto, com os covenants, alguns novos projetos de canais de estado podem ser feitos em cima da Lightning Network 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. Pegando a sigla de “L2”, essa tecnologia propõe uma camada de execução para a Lightning Network que permite que qualquer estado do canal posterior substitua o estado anterior sem um mecanismo de penalidade, 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).
O Ark visa reduzir a dificuldade de gerenciamento de liquidez de entrada e canais da rede lightning. É um protocolo na forma de joinpool, onde múltiplos usuários podem aceitar um provedor de serviços como contraparte por um certo período de tempo e negociar UTXOs virtuais (vUTXOs) off-chain, mas compartilham um UTXO on-chain para reduzir os custos. Semelhante a cofres, o Ark pode ser implementado na rede Bitcoin atual; no entanto, com a introdução de covenants, o Ark pode reduzir a quantidade de interação necessária com base em modelos de transação, possibilitando uma saída unilateral mais confiável.
Como pode ser visto nas aplicações acima, os convênios são mais como um efeito do que uma tecnologia específica e, como tal, existem muitas maneiras técnicas de implementá-los. Eles podem ser categorizados como:
Aqui, recursivo significa: existem algumas implementações de convênios que também podem limitar a saída da próxima transação ao limitar 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:
Como pode ser visto na introdução anterior, os scripts atuais do Bitcoin principalmente restringem as condições para desbloqueio e não restringem como aquele UTXO pode ser gasto posteriormente. Para implementar acordos, precisamos pensar de forma inversa: por que os scripts atuais do Bitcoin não podem implementar acordos?
O principal motivo é que os scripts atuais do Bitcoin não podem ler a própria transação, o que significa a introspecção da transação.
Se pudéssemos implementar a introspecção - inspecionando qualquer coisa na transação (incluindo a saída) - então poderíamos implementar pactos.
Portanto, o design dos pactos também é centrado em como implementar a introspecção.
A ideia mais simples e mais grosseira é 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 opcode.
Outra forma de pensar é que, em vez de ler e verificar o conteúdo da própria transação diretamente no script, pode-se usar o hash do conteúdo da transação, o que significa que se este hash foi assinado, então, transformando opcodes como OP_CHECKSIG no script para verificar esta assinatura, é possível implementar indiretamente a introspecção da transação e covenants. Esta ideia é baseada na abordagem de design de assinatura. Inclui principalmente APO e OP_CSFS.
SIGHASH_ANYPREVOUT (APO) é uma proposta para um hash de assinatura. A maneira mais simples de assinar é se comprometer tanto com 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 faixa atual de SIGHASH e suas combinações de assinaturas para as entradas e saídas de transações (fonte: Dominando o Bitcoin, 2ª edição)
Como mostrado acima, além de TODOS, que se aplica a todos os dados, NENHUM é assinado de tal forma que se aplica apenas a todas as entradas e não a saídas, e ÚNICO se baseia nisso ao aplicá-lo apenas a saídas com o mesmo número de índice de entrada. Além disso, SIGHASH pode ser combinado, com o modificador ANYONECANPAY sobreposto, para se aplicar apenas a uma entrada.
SIGHASH do APO, por outro lado, apenas assina 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.
Essa flexibilidade é a justificativa por trás da implementação de convênios da APO:
Vale ressaltar que, como esta chave pública não tem uma chave privada correspondente, garante que esses ativos só podem ser gastos por meio de transações pré-criadas. Então, 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 sacar dinheiro de um endereço contratado se certas condições forem atendidas, em vez de gastá-lo arbitrariamente com uma assinatura EOA. Sob esse ponto de vista, o Bitcoin pode alcançar esse efeito por meio de melhorias no mecanismo de assinatura.
O problema com o processo acima, no entanto, é que há um dev@lists.linuxfoundation.org/msg08075.html">dependência circular no cálculo, pois é necessário saber 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 o problema de dependência circular ao precisar apenas conhecer (especificar) a saída completa da transação no momento da computação.
OP_CHECKTEMPLATEVERIFY (CTV), ou BIP-119, usa uma melhoria no Opcode. Ele recebe o hash de compromisso como argumento e exige que qualquer transação que execute um opcode contenha um conjunto de saídas que correspondam a esse compromisso. Com o CTV, permitiria aos usuários de Bitcoin limitar como eles usam o Bitcoin.
Originalmente introduzido como OP_CHECKOUTPUTSHASHVERIFY (COSHV) e com um foco inicial na capacidade de criar transações de controle de congestionamento, as críticas à proposta também se concentraram no fato de que não é genérica o suficiente e é muito específica para o caso de uso de controle de congestionamento.
No caso de uso de controle de congestionamento mencionado acima, Alice, a remetente, poderia criar 10 saídas e fazer hash dessas 10 saídas, e usar o resumo 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 todas as 10 saídas para que cada um deles possa verificar a transação de configuração de Alice. Quando desejam gastar o pagamento posteriormente, qualquer um deles pode criar uma transação com as saídas comprometidas.
Durante o processo, à medida que Alice cria e envia a transação de configuração, Alice pode enviar essas 10 cópias das saídas através de métodos de comunicação assíncrona existentes, como e-mail ou drives na nuvem. Isso significa que os destinatários não precisam estar online ou interagir entre si.
Fonte: https://bitcoinops.org/en/newsletters/2019/05/29/#proposed-transaction-output-commitments
Assim como os APOs, endereços podem ser construídos com base em condições de gastos, e "travas" podem ser feitas de diferentes maneiras, incluindo chaves extras, timelocks relativos ou fixos e outras lógicas para combiná-las.
Fonte: https://twitter.com/OwenKemeys/status/1741575353716326835
Com base nisso, a CTV propõe verificar se a transação gasta após o hash corresponde à definida, o que significa que os dados da transação são usados como a chave para desbloquear o "bloqueio".
Podemos estender o exemplo acima de 10 destinatários, onde um destinatário pode fazer com que 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 usuários 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-camada unidimensional para uma árvore de pagamento multi-camada multidimensional, e os cenários que podem ser suportados serão mais ricos e flexíveis.
Fonte: 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 recebeu muita discussão da comunidade, atualizações e debates sobre 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, como descrito no parágrafo de abertura, é também uma proposta de atualização que está atualmente recebendo muita atenção e implementa uma função que concatena dois elementos ou dois conjuntos de dados da pilha. Embora pareça simples, OP_CAT é muito flexível e pode ser implementado em scripts de várias maneiras.
O exemplo mais direto é a operação da Árvore de Merkle, que pode ser interpretada como a concatenação de dois elementos e, em seguida, hash. Atualmente, existem OP_SHA256 e outros códigos de operação de hash no script do Bitcoin, então, se você puder concatenar dois elementos usando OP_CAT, poderá 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 em certa medida.
Outra base para a implementação é o aprimoramento das assinaturas de Schnorr: você pode definir a condição de assinatura de gasto de um script para ser uma concatenação da chave pública do usuário e 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 compromisso com o nonce e assim 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.
OP_CAT por si só não é uma nova funcionalidade, pois existia nas primeiras versões do Bitcoin, mas foidesativadoem 2010 devido ao seu potencial de 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 esses scripts, como visto neste demo.
Mas não ocorrerá o problema de explosão de pilha mencionado anteriormente nos dias de hoje, uma vez que o OP_CAT foi reativado? Porque a proposta atual do OP_CAT envolve apenas ativá-lo no tapscript, que tem um limite de 520 bytes por elemento de pilha, não causará o problema de explosão de pilha anterior. Também há alguns desenvolvedores que acham que Satoshi Nakamoto pode ter sido muito rigoroso ao desativar o OP_CAT completamente. No entanto, devido à flexibilidade do OP_CAT, pode ser verdade 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, o OP_CAT tem recebido muita atenção recentemente e também teve um revisão de PR, e é atualmente uma das propostas de atualização mais quentes.
A 'Autorregulação Traz Liberdade', como pode ser visto na introdução acima, os acordos podem ser implementados diretamente nos scripts do Bitcoin para qualificar mais gastos em transações, permitindo assim regras de transações semelhantes ao efeito dos contratos inteligentes. Esta abordagem de programação pode ser verificada de forma mais nativa no Bitcoin do que abordagens off-chain como BitVM e também pode melhorar aplicativos na cadeia principal (controle de congestionamento), aplicativos off-chain (canal de estado) e outras novas direções de aplicativos (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
na revisãopode ser combinado ainda mais com o propostoOP_TLUVou outras cláusulas que poderiam ser programadas com base no número de satoshis gerados por uma transação.
No entanto, os pactos também podem levar a abusos ou vulnerabilidades não planejados, então 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 soft fork das regras de consenso. Dadas as circunstâncias em torno da atualização do taproot, é provável que a atualização relacionada aos pactos também leve tempo para ser concluída.
Obrigado Ajian, FishereBenpara revisão e sugestões!
Aviso Legal: Este material é apenas para fins de informação geral e não constitui, nem deve ser interpretado como, qualquer forma de conselho de investimento, solicitação ou oferta de investimentos, e nenhuma responsabilidade é aceita pela HashKey Capital 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/
Este artigo foi reproduzido a partir de [médio], o direito autoral pertence ao autor original [Jeffrey HueHarper Li], se você tiver alguma objeção à reprodução, entre em contato com o Gate Learnequipe , e a equipe lidará com isso o mais breve possível de acordo com os procedimentos relevantes.
Aviso legal: As visões e opiniões expressas neste artigo representam apenas as visões pessoais do autor e não constituem nenhum conselho de investimento.
Outras versões do artigo em outros idiomas são traduzidas pela equipe Gate Learn e não são mencionadas em Gate, o artigo traduzido não pode ser reproduzido, distribuído ou plagiado.
Пригласить больше голосов
Os "Pactos" 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 de 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 apresentadas e como elas melhoram a programabilidade e as 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 possíveis disputas na comunidade.
Co-escrito por Jeffrey HueHarper Li
Houve recentemente uma onda de discussão na comunidade Bitcoin sobre a reativação de opcodes como OP_CAT, e o Taproot Wizard atraiu muita atenção ao lançar o NFT dos Quantum Cats, alegando ter recebido a atribuição BIP-420. Os defensores afirmam que a ativação do OP_CAT irá realizar "pactos", e assim trazer contratos inteligentes ou programabilidade ao Bitcoin.
Se você notar a palavra “covenants” e fizer uma pequena pesquisa, verá que este é mais um grande buraco de coelho. Os desenvolvedores vêm falando há anos sobre tecnologias que implementam covenants, como OP_CTV, APO, OP_VAULT e mais, além de OP_CAT.
Mais precisamente, os scripts atuais do Bitcoin também possuem alguns tipos de pactos, como bloqueios de tempo baseados em opcode, que são implementados por meio da introspecção do campo nLock ou nSequence da transação para limitar a quantidade de tempo antes que a transação possa ser gasta, mas ainda estão apenas limitados a restrições de tempo.
Então, o que exatamente são os 'pactos' do Bitcoin? Por que tem atraído tanta atenção e discussão dos desenvolvedores há 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.
Pacto é um mecanismo que pode definir condições para 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 em conformidade ao gastar. Desde que o usuário consiga desbloqueá-lo, ele pode gastar esse UTXO onde desejar.
O Pacto é impor mais restrições além dessa limitação sobre como desbloquear, como limitar os gastos de UTXO após ser gasto, que é para alcançar um efeito semelhante ao de reserva, ou outras condições de entrada inseridas em uma transação, etc.
Então, por que os desenvolvedores e pesquisadores projetam essas verificações de restrição? Isso ocorre porque os covenants não são apenas restrições por nada, mas sim definir as regras para a execução do comércio. Dessa forma, o usuário só pode executar transações de acordo com as regras pré-definidas, completando assim o processo de negócios pretendido.
Então, de maneira contra-intuitiva, isso traz mais cenários de aplicação.
Um dos exemplos mais intuitivos de uma aliança é a transação de corte de Babilônia no processo de staking do Bitcoin.
O processo de staking de Bitcoin da Babilônia envolve os usuários enviando seu BTC para um script especial na main chain com duas condições de gasto:
Origem: Bitcoin Staking: Desbloqueando 21M Bitcoins para Segurar a Economia de Prova de Participação
Observe 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 consiga transferir 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 códigos de operação ao "fim ruim" do script de staking.
Antes que o OP_CTV seja ativado, Babilônia precisará de uma solução alternativa para emular o efeito de fazer cumprir os pactos, tendo o usuário + comitê trabalhando juntos.
Em termos gerais, a congestão ocorre quando a taxa está alta no Bitcoin com um número relativamente grande de transações acumuladas na pool de transações aguardando para serem empacotadas, então se um usuário deseja confirmar uma transação rapidamente, ele ou ela precisa aumentar a taxa.
Nesse ponto, se um usuário tiver que enviar várias transações para vários endereços, ele terá que aumentar suas taxas e incorrer em custos mais altos. Consequentemente, isso aumentará ainda mais a taxa de transação de toda a rede.
Se houver um pacto, então existe 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 esperar até que a taxa esteja baixa antes de enviar a transação específica.
Conforme mostrado abaixo, quando a demanda por espaço de bloco é alta, torna-se muito caro conduzir transações. Ao usar OP_CHECKTEMPLATEVERIFY, um processador de pagamento de alto volume pode agregar todos os seus pagamentos em uma única transação O(1) para confirmação. Então, 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
Origem: https://utxos.org/usos/escalabilidade/
Este cenário é um dos casos de uso mais típicos apresentados por esta restrição OP_CTV. Muitos outros casos de uso podem ser encontrados em https://utxos.org/uses.Além do controle de congestionamento mencionado acima, a página lista Apostas Soft Fork, opções descentralizadas, Drivechains, Canais de lote, Canais não interativos, Pools de mineração sem coordenação de confiança, Vaults, Contratos mais seguros com Tempo Fechado Hashed (HTLCS) Limites, e mais.
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 inevitavelmente envolvem equilibrar a necessidade de manter os fundos seguros com a necessidade de usá-los, gostaríamos de ter um cofre que possa manter os fundos seguros, ou até mesmo restringir 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.
Tomemos o esquema de design do OP_VAULT como exemplo: ao gastar fundos no cofre, uma transação precisa ser enviada para a cadeia primeiro. Essa transação indica a intenção de gastar o cofre, que é um "gatilho", e condições são definidas nela:
Processo de OP_VAULT, fonte: BIP-345
Note que também é possível construir um cofre sem pactos, e uma maneira possível de fazer isso é usar uma chave privada para preparar uma assinatura para gastos posteriores e, em seguida, destruir essa chave privada. No entanto, ainda existem mais limitações, como a necessidade de garantir que a chave privada tenha sido destruída (similar ao processo de configuração confiável em provas de conhecimento zero) e a falta de flexibilidade na determinação do valor e da taxa antecipadamente (por causa da pré-assinatura).
Cofres pré-calculados e OP_VAULT, fonte: BIP-345
Geralmente, pode-se assumir que os canais de estado, incluindo a Lightning Network, têm praticamente a mesma segurança que a cadeia principal (em termos de garantir que os nós possam observar o estado mais recente e possam postar corretamente o estado mais recente na cadeia). No entanto, com os covenants, alguns novos projetos de canais de estado podem ser feitos em cima da Lightning Network 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. Pegando a sigla de “L2”, essa tecnologia propõe uma camada de execução para a Lightning Network que permite que qualquer estado do canal posterior substitua o estado anterior sem um mecanismo de penalidade, 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).
O Ark visa reduzir a dificuldade de gerenciamento de liquidez de entrada e canais da rede lightning. É um protocolo na forma de joinpool, onde múltiplos usuários podem aceitar um provedor de serviços como contraparte por um certo período de tempo e negociar UTXOs virtuais (vUTXOs) off-chain, mas compartilham um UTXO on-chain para reduzir os custos. Semelhante a cofres, o Ark pode ser implementado na rede Bitcoin atual; no entanto, com a introdução de covenants, o Ark pode reduzir a quantidade de interação necessária com base em modelos de transação, possibilitando uma saída unilateral mais confiável.
Como pode ser visto nas aplicações acima, os convênios são mais como um efeito do que uma tecnologia específica e, como tal, existem muitas maneiras técnicas de implementá-los. Eles podem ser categorizados como:
Aqui, recursivo significa: existem algumas implementações de convênios que também podem limitar a saída da próxima transação ao limitar 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:
Como pode ser visto na introdução anterior, os scripts atuais do Bitcoin principalmente restringem as condições para desbloqueio e não restringem como aquele UTXO pode ser gasto posteriormente. Para implementar acordos, precisamos pensar de forma inversa: por que os scripts atuais do Bitcoin não podem implementar acordos?
O principal motivo é que os scripts atuais do Bitcoin não podem ler a própria transação, o que significa a introspecção da transação.
Se pudéssemos implementar a introspecção - inspecionando qualquer coisa na transação (incluindo a saída) - então poderíamos implementar pactos.
Portanto, o design dos pactos também é centrado em como implementar a introspecção.
A ideia mais simples e mais grosseira é 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 opcode.
Outra forma de pensar é que, em vez de ler e verificar o conteúdo da própria transação diretamente no script, pode-se usar o hash do conteúdo da transação, o que significa que se este hash foi assinado, então, transformando opcodes como OP_CHECKSIG no script para verificar esta assinatura, é possível implementar indiretamente a introspecção da transação e covenants. Esta ideia é baseada na abordagem de design de assinatura. Inclui principalmente APO e OP_CSFS.
SIGHASH_ANYPREVOUT (APO) é uma proposta para um hash de assinatura. A maneira mais simples de assinar é se comprometer tanto com 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 faixa atual de SIGHASH e suas combinações de assinaturas para as entradas e saídas de transações (fonte: Dominando o Bitcoin, 2ª edição)
Como mostrado acima, além de TODOS, que se aplica a todos os dados, NENHUM é assinado de tal forma que se aplica apenas a todas as entradas e não a saídas, e ÚNICO se baseia nisso ao aplicá-lo apenas a saídas com o mesmo número de índice de entrada. Além disso, SIGHASH pode ser combinado, com o modificador ANYONECANPAY sobreposto, para se aplicar apenas a uma entrada.
SIGHASH do APO, por outro lado, apenas assina 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.
Essa flexibilidade é a justificativa por trás da implementação de convênios da APO:
Vale ressaltar que, como esta chave pública não tem uma chave privada correspondente, garante que esses ativos só podem ser gastos por meio de transações pré-criadas. Então, 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 sacar dinheiro de um endereço contratado se certas condições forem atendidas, em vez de gastá-lo arbitrariamente com uma assinatura EOA. Sob esse ponto de vista, o Bitcoin pode alcançar esse efeito por meio de melhorias no mecanismo de assinatura.
O problema com o processo acima, no entanto, é que há um dev@lists.linuxfoundation.org/msg08075.html">dependência circular no cálculo, pois é necessário saber 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 o problema de dependência circular ao precisar apenas conhecer (especificar) a saída completa da transação no momento da computação.
OP_CHECKTEMPLATEVERIFY (CTV), ou BIP-119, usa uma melhoria no Opcode. Ele recebe o hash de compromisso como argumento e exige que qualquer transação que execute um opcode contenha um conjunto de saídas que correspondam a esse compromisso. Com o CTV, permitiria aos usuários de Bitcoin limitar como eles usam o Bitcoin.
Originalmente introduzido como OP_CHECKOUTPUTSHASHVERIFY (COSHV) e com um foco inicial na capacidade de criar transações de controle de congestionamento, as críticas à proposta também se concentraram no fato de que não é genérica o suficiente e é muito específica para o caso de uso de controle de congestionamento.
No caso de uso de controle de congestionamento mencionado acima, Alice, a remetente, poderia criar 10 saídas e fazer hash dessas 10 saídas, e usar o resumo 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 todas as 10 saídas para que cada um deles possa verificar a transação de configuração de Alice. Quando desejam gastar o pagamento posteriormente, qualquer um deles pode criar uma transação com as saídas comprometidas.
Durante o processo, à medida que Alice cria e envia a transação de configuração, Alice pode enviar essas 10 cópias das saídas através de métodos de comunicação assíncrona existentes, como e-mail ou drives na nuvem. Isso significa que os destinatários não precisam estar online ou interagir entre si.
Fonte: https://bitcoinops.org/en/newsletters/2019/05/29/#proposed-transaction-output-commitments
Assim como os APOs, endereços podem ser construídos com base em condições de gastos, e "travas" podem ser feitas de diferentes maneiras, incluindo chaves extras, timelocks relativos ou fixos e outras lógicas para combiná-las.
Fonte: https://twitter.com/OwenKemeys/status/1741575353716326835
Com base nisso, a CTV propõe verificar se a transação gasta após o hash corresponde à definida, o que significa que os dados da transação são usados como a chave para desbloquear o "bloqueio".
Podemos estender o exemplo acima de 10 destinatários, onde um destinatário pode fazer com que 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 usuários 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-camada unidimensional para uma árvore de pagamento multi-camada multidimensional, e os cenários que podem ser suportados serão mais ricos e flexíveis.
Fonte: 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 recebeu muita discussão da comunidade, atualizações e debates sobre 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, como descrito no parágrafo de abertura, é também uma proposta de atualização que está atualmente recebendo muita atenção e implementa uma função que concatena dois elementos ou dois conjuntos de dados da pilha. Embora pareça simples, OP_CAT é muito flexível e pode ser implementado em scripts de várias maneiras.
O exemplo mais direto é a operação da Árvore de Merkle, que pode ser interpretada como a concatenação de dois elementos e, em seguida, hash. Atualmente, existem OP_SHA256 e outros códigos de operação de hash no script do Bitcoin, então, se você puder concatenar dois elementos usando OP_CAT, poderá 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 em certa medida.
Outra base para a implementação é o aprimoramento das assinaturas de Schnorr: você pode definir a condição de assinatura de gasto de um script para ser uma concatenação da chave pública do usuário e 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 compromisso com o nonce e assim 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.
OP_CAT por si só não é uma nova funcionalidade, pois existia nas primeiras versões do Bitcoin, mas foidesativadoem 2010 devido ao seu potencial de 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 esses scripts, como visto neste demo.
Mas não ocorrerá o problema de explosão de pilha mencionado anteriormente nos dias de hoje, uma vez que o OP_CAT foi reativado? Porque a proposta atual do OP_CAT envolve apenas ativá-lo no tapscript, que tem um limite de 520 bytes por elemento de pilha, não causará o problema de explosão de pilha anterior. Também há alguns desenvolvedores que acham que Satoshi Nakamoto pode ter sido muito rigoroso ao desativar o OP_CAT completamente. No entanto, devido à flexibilidade do OP_CAT, pode ser verdade 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, o OP_CAT tem recebido muita atenção recentemente e também teve um revisão de PR, e é atualmente uma das propostas de atualização mais quentes.
A 'Autorregulação Traz Liberdade', como pode ser visto na introdução acima, os acordos podem ser implementados diretamente nos scripts do Bitcoin para qualificar mais gastos em transações, permitindo assim regras de transações semelhantes ao efeito dos contratos inteligentes. Esta abordagem de programação pode ser verificada de forma mais nativa no Bitcoin do que abordagens off-chain como BitVM e também pode melhorar aplicativos na cadeia principal (controle de congestionamento), aplicativos off-chain (canal de estado) e outras novas direções de aplicativos (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
na revisãopode ser combinado ainda mais com o propostoOP_TLUVou outras cláusulas que poderiam ser programadas com base no número de satoshis gerados por uma transação.
No entanto, os pactos também podem levar a abusos ou vulnerabilidades não planejados, então 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 soft fork das regras de consenso. Dadas as circunstâncias em torno da atualização do taproot, é provável que a atualização relacionada aos pactos também leve tempo para ser concluída.
Obrigado Ajian, FishereBenpara revisão e sugestões!
Aviso Legal: Este material é apenas para fins de informação geral e não constitui, nem deve ser interpretado como, qualquer forma de conselho de investimento, solicitação ou oferta de investimentos, e nenhuma responsabilidade é aceita pela HashKey Capital 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/
Este artigo foi reproduzido a partir de [médio], o direito autoral pertence ao autor original [Jeffrey HueHarper Li], se você tiver alguma objeção à reprodução, entre em contato com o Gate Learnequipe , e a equipe lidará com isso o mais breve possível de acordo com os procedimentos relevantes.
Aviso legal: As visões e opiniões expressas neste artigo representam apenas as visões pessoais do autor e não constituem nenhum conselho de investimento.
Outras versões do artigo em outros idiomas são traduzidas pela equipe Gate Learn e não são mencionadas em Gate, o artigo traduzido não pode ser reproduzido, distribuído ou plagiado.