Covenants Bitcoin: Op_vault (BIP 345)

Este é o quarto artigo em um série Mergulhar profundamente em propostas individuais de aliança que atingiram um ponto de maturidade que merecem um detalhamento aprofundado.

Op_vault, apresentado por James O'Beirne no BIP 345 (com Greg Sanders adicionado mais tarde como co-autor), é uma aliança projetada para implementar cofres. Além disso, depende do CTV (ou TXHASH ou de outros códigos de operações semelhantes) para concluir a construção de um cofre.

Antes de entrar em como a proposta em si funciona, vejamos o que um cofre está tentando realizar.

O objetivo de um cofre é melhorar a segurança do seu armazenamento de bitcoin. Isso é realizado pela introdução de um período de atraso durante qualquer tentativa de gastar no cofre. Em vez de poder enviar diretamente seu bitcoin do cofre, o cofre os restringe para que eles só possam ser enviados para um endereço de “meio termo”. Embora as moedas sejam retiradas do cofre estejam nesse estado médio, elas podem ser gastas a qualquer momento em uma carteira de armazenamento frio profundo sob seu controle (idealmente um Vault Multisig geograficamente distribuído) e apenas para esse profundo armazenamento a frio. Após um cronograma predefinido, as moedas podem ser gastas no destino final.

Isso é algo que é possível fazer atualmente com transações pré-assinadas, mas isso traz um grande grau de complexidade, ineficiência, falta de flexibilidade e risco de perder fundos.

O uso de transações pré-assinadas exige que você decida com antecedência quanto dinheiro será retirado de cada vez, o que o FEEREATE as transações que se retiram do cofre pagarão, o que é o endereço intermediário antes de retirar totalmente e depois você ter Para excluir com segurança as chaves privadas usadas para pré-assinar todas essas transações.

Um grande problema com essa arquitetura, além das restrições gerais de quantidades pré-decididas, taxas, etc., é que a reutilização do endereço não é segura. Em um esquema de cofre de transação pré-assinado, os depósitos são enviados para o endereço usado para assinar a transação inicial do Vault e que, juntamente com todas as outras teclas envolvidas, são excluídas após a assinatura das transações do Vault. A reutilização do endereço é uma prática ruim, mas você não pode impedir que outra pessoa envie fundos para um endereço que eles já usaram antes. Quaisquer fundos posteriores depositados seriam perdidos para sempre, pois todas as chaves do cofre foram excluídas.

Além disso, todo depósito em um cofre exige uma nova configuração de novas chaves, conduzindo a cerimônia de pré-assinatura novamente para o novo conjunto de transações, garantindo que o novo conjunto de chaves seja excluído com segurança e gerenciando o armazenamento adequado de todas essas informações, incluindo backups redundantes. Cada depósito cria uma oportunidade para que algo fique bagunçado durante a configuração do cofre, todo depósito oferece uma chance para alguém que comprometeu um sistema ou dispositivo desde o último depósito para tentar roubar seus fundos.

Os cofres de transação pré-assinados são uma construção complicada e complicada, e apresentam complexidade suficiente que cada uso apresenta um risco não negligenciável de bagunçar de uma maneira que resulta em fundos perdidos.

As melhorias podem ser feitas com a CTV, como acabar com a necessidade de excluir as chaves com segurança, mas o restante da complexidade e risco ainda permanece. Valores e taxas ainda devem ser predefinidos. A reutilização do endereço ainda pode levar à perda de fundos.

Como o op_vault funciona

Op_vault é construído no Taproot, o que significa que todo o design usa o TAPScript e depende da existência de taptrees e do caminho de gastos com script. Também depende do uso de CTV (ou TXHASH/funcionalidade semelhante) para construir um cofre completo.

A proposta são na verdade dois OPCodes, OP_Vault e OP_Vault_recover. Op_vault é usado para desencadear saques do cofre, e o OP_Vault_recover é usado para varrer os retiradas acionadas na carteira de recuperação profunda. A idéia é construir um taptree que tenha caminhos op_vault nele para retiradas, e os caminhos up_vault_recover para varrer quaisquer fundos no meio do coletor para uma carteira fria segura. Este taptree é o seu cofre.

OP_Vault funciona restringindo como as saídas de uma transação gastando uma moeda oplumed op_vault deve procurar. O código de opção espera na testemunha:

• Um corpo de script tapleaf
• O número de peças de dados para uma atualização de script
• Um índice de saída para a retirada
• Um índice de saída para quaisquer fundos que voltem ao cofre
• Uma quantidade de Satoshis voltando ao cofre

Op_vault garante que a quantidade correta de fundos enviados de volta ao cofre esteja correta e que o script de saída dessa saída seja idêntico até o taptree sendo gasto. Ele também pega o corpo do script tapleaf e as variáveis ​​de dados fornecidas e as combina em um script completo. Em seguida, garante que a saída especificada para retirada tenha um script idêntico com o taptree da entrada que está sendo gasta, exceto O Tapleaf sendo gasto é substituído pelo script de folhas de Taps, juntamente com dados da testemunha.

Esse último truque é possível porque, para verificar se o Tapleaf faz parte do taptree, em primeiro lugar, os nós interiores da árvore de Merkle devem estar presentes para verificar. Hashing o novo script com as folhas interiores conhecidas do resto da árvore garante que apenas a folha da árvore fosse alterada. O modelo para o script que seja preenchido dinamicamente é definido no momento da criação do cofre. Para um caso de uso típico do cofre, o modelo de script seria simplesmente um caminho de gasto com ctv cronometido com o hash fornecido ao desencadear uma retirada.

Op_vault_recover é muito mais simples. É preciso um hash do script de recuperação e um índice de saída para a transação de recuperação. Essa saída deve conter um script que corresponda exatamente ao hash predefinido e a totalidade da quantidade de fundos na entrada que está sendo recuperada deve ir para essa saída.

Ambos os scripts podem ser “fechados” com um script de autorização, ou seja, fornecendo uma assinatura de uma chave específica para desencadear uma retirada ou iniciar uma recuperação. Isso tem algumas compensações. Se você perder uma chave de autorização de recuperação, não poderá mais acionar uma transação de recuperação no caso de um roubo da sua chave de gatilho de retirada. No entanto, permite que você inicie uma recuperação de vários UTXOs do Vault na mesma transação devido à especificação de saídas correspondentes de cada entrada manualmente.

Para que op_vault é bom para

Obviamente, cofres. Op_vault aborda de forma limpa todas as principais limitações de uma transação pré-assinada ou Vault baseado em CTV. Nenhuma denominações pré-decididas restritivas ou taxas pré-decididas, nenhum perigo na reutilização de endereços e nenhuma necessidade de lidar com um problema de alta segurança, como a deleção de chave todas as vezes que você depositar.

É muito mais flexível do que apenas cofres. Esse foi o caso de uso pretendido quando foi projetado, mas é uma aliança muito mais geral, garantindo que um taptree realmente leve para o próximo UTXO quando você deseja, com condições de saída predefinidas que têm algum grau de flexibilidade.

Você pode fazer algo muito próximo de um drivechain com op_vault. Crie um modelo de cofre que tenha um cronograma incrivelmente longo, da ordem de 3-6 meses (semelhante aos retiradas de drivechain). Não tenha portão de autorização para nenhum script e torne o modelo público. Agora, as pessoas podem simplesmente depositar fundos no “DriveChain” enviando dinheiro para esse script cofre. Qualquer pessoa pode propor uma retirada simplesmente gastando a partir de um caminho OP_Vault e incluindo um hash de CTV de sua transação de retirada. Os mineradores podem aplicar isso simplesmente recusando -se a extrair quaisquer transações inválidas de retirada e, se um mineiro malicioso extraiu um gatilho de retirada malicioso, o próximo mineiro honesto poderia simplesmente rever os fundos.

É isso que pode ser feito apenas usando um modelo de script idêntico, conforme recomendado no BIP. O modelo de script definido para saques é arbitrário e, como tal, é potencialmente muito geral em termos de que tipos de auto -contratos perpetuados OP_Vault podem ativar.

Pensamentos finais

Op_vault atinge claramente o objetivo de permitir cofres adequados que não vêm com as restrições, complexidades e o risco de que os cofres de transação pré-assinados (ou covenant covenant ainda mais simples com algo como CTV) venham. No entanto, ao fazer isso, acabou introduzindo um conjunto de funcionalidades bastante amplo e generalizado para atingir esse objetivo original.

A proposta permitiria definitivamente uma funcionalidade de cofre relativamente suave e segura, mas também abre muitas outras portas. O DriveChains é algo que vem com um grande grau de risco centrado em torno do valor extractável de mineiro (MEV). As desvantagens de permitir essa funcionalidade e as questões e consequências de incentivo que poderiam ter devem ser pesadas contra a vantagem de permitir um cofre bem construído.

Op_vault é uma proposta relativamente madura, mas o grau de funcionalidade que permite não deve ser abordado de ânimo leve.