Covenants de Bitcoin: CheckTemPlutytify (BIP 119)

O primeiro artigo é aprofundado em propostas individuais de aliança que atingiram um ponto de maturidade que merecem um detalhamento profundo.

O CheckTemPlatemedify (CTV), apresentado por Jeremy Rubin com o BIP 119, é a proposta de aliança mais madura e totalmente desenvolvida, não apenas das propostas que abordaremos, mas de todas as propostas da aliança em sua totalidade. Como mencionei no artigo de introdução desta série, há muitas preocupações no ecossistema em relação aos convênios que são muito flexíveis, permitindo coisas que acabam tendo consequências muito prejudiciais para o Bitcoin.

A CTV foi projetada especificamente para restringir suas capacidades com força suficiente para evitar qualquer uma dessas preocupações. Para entender primeiro como as funções do CTV, precisamos entender as partes individuais de uma transação de bitcoin.

Esta é uma visão de nível muito alto da transação de bitcoin. Possui entradas, ou moedas não gastas (UTXOS) e saídas, as novas moedas não gastas que a transação criará quando for confirmada em um bloco. Há muito mais peças pelas quais passaremos, mas essa é a visão mais alta da estrutura de uma transação.

Toda transação também possui um campo de número de versão para toda a transação, indicando aplicabilidade de novas versões de regras ou recursos. Há também o marcador e o sinalizador, que são definidos como valores específicos para indicar que a transação usa segwit. Depois disso é a contagem de entrada, o número de entradas na transação. Então venha as entradas reais.

Cada entrada contém um TXID da transação que criou a moeda não gasta gasta, um VOUT que marca qual a saída nessa transação está sendo gasta, o tamanho do scriptsig e o scriptsig, que é o script de desbloqueio que a entrada é gasto em seu script, e finalmente o número de sequência é usado para garantir que o número de scripts que seja usado. Ou seja, a entrada existe para um certo número de blocos ou tempo desde a sua criação.

A contagem de saída é a próxima peça de dados, o número de saídas na transação. Depois disso, as saídas reais, que contêm uma quantidade de Satoshis atribuídos a essa saída, o tamanho do scriptpubKey e o scriptpubkey real, que é o script de travamento para essa saída. Por fim, o campo NLOCKTIME aplica um valor de timelock no timestamp ou altura do bloco que se aplica a toda a transação.

Cada transação segwit também contém uma seção de testemunhas, onde cada entrada possui uma testemunha correspondente contendo uma contagem de itens de pilha, quantas coisas serão colocadas na pilha de scripts, um campo de tamanho para cada item e o item de dados real para entrar na pilha.

Como funciona a CTV

O CTV é um código de opção que permite a forma mais básica de introspecção e dados de encaminhamento que realizam todas as propostas da aliança. Ele permite que um script pegue um hash predefinido de 32 bytes e compare isso com um hash da maioria dos campos da transação de gastos. Se o hash derivado da transação de gastos real não corresponder ao hash predefinido, a transação será inválida.

Os campos aos quais ele se compromete são:

• nversion
• NlockTime
• Contagem de entrada
• Um hash de todos os campos de NEFENCÊNCIA
• Contagem de saída
• Um hash de todas as saídas
• Índice de entrada (o local em que a entrada possui na transação, 1ª entrada, 2ª, etc.)

Estes são todos os campos cometidos pelo hash da CTV, na íntegra e sem capacidade de escolher. Este é o grau de introspecção que o CTV permite: “O hash desses campos na transação de gastos corresponde ao hash no script de travamento da entrada gasta”, é isso. O hash se compromete a essencialmente toda a transação, exceto as entradas reais. Há uma razão para o hash não incluir as entradas. Para bloquear uma saída em um hash de 32 bytes com CTV, você precisa conhecer o hash da transação que está garantindo que seja a única maneira de ser gasto. A entrada bloqueada com a CTV gasta terá que incluir este hash para ser verificado contra a CTV. Isso requer ter o hash dessa transação antes Você cria a transação completa. Isso não é possível.

Você também pode aninhar os scripts do CTV, ou seja, um script inicial de CTV se comprometer com uma transação com saídas que também incluem scripts de CTV. É isso que permite que o CTV “carregue” dados. Tudo o que leva adiante na prática, porém, são os dados contidos na cadeia de transações. Você pode fazer isso em teoria a uma profundidade infinita, mas é limitado na prática a uma profundidade finita, porque o ninho deve ser gerado para trás a partir do final. Isso ocorre porque cada nível, ou “salto”, deve ter o hash da transação se movendo para o próximo, caso contrário você não pode criar o script de travamento em primeiro lugar. Se você ainda não conhece a próxima transação, não pode gerar a anterior.

Para que CTV é útil para

A CTV permite restringir uma saída para que ele só possa ser gasto, de acordo com as regras de consenso, por uma transação predefinida exata. Alguns de vocês podem estar perguntando qual é o problema, já podemos pré-assinar transações. Se o nível de introspecção for tão limitado que só pode realizar algo que já podemos fazer apenas pré-assinatura, qual é o valor agregado?

Primeiro, as transações pré-assinadas sempre deixam em aberto a possibilidade de o (s) detentor (s) assinar novas transações e gastar essas moedas de uma maneira diferente. Você deve confiar que o detentor não fará isso ou excluirá a chave necessária para assinar (em que você também deve confiar neles). A CTV remove essa confiança completamente. Depois que a transação de gastos é definida e a saída bloqueada para o hash da CTV é criada, não há possibilidade de ser gasto de outra maneira, imposta por consenso.

Atualmente, a única maneira de contornar essa confiança é estar envolvido na pré-assinatura de transações usando o Multisig. Então você pode ter certeza de que, a menos que você opte por assinar um, nenhuma outra transação válida gastando uma moeda de uma maneira diferente pode ser criada. O problema é que quanto mais pessoas estão envolvidas, mais difíceis e não confiáveis ​​coordenando todos para assinar uma transação ao mesmo tempo. PASSO TAMANHOS PASTOS, Torna -se um problema totalmente impraticável resolver de maneira confiável.

A CTV dá uma maneira de as pessoas saberem que um conjunto de transações é cometido sem que todos tenham que ficar on -line ao mesmo tempo para assiná -las. Simplifica muito o processo de coordenação, permitindo que todos obtenham as informações necessárias para qualquer outra pessoa sempre que puderem, e uma vez que essa pessoa tiver informações de todos, pode criar a cadeia de transações de CTV sem o envolvimento de mais ninguém, e todos podem verificar e ter certeza de que o resultado correto é o único possível.

Isso é incrivelmente valioso por si só, mas a CTV também pode permitir coisas ainda mais valiosas em combinação com outros códigos de OPC, que veremos no próximo artigo.

Pensamentos finais

O CTV é um pacto bem restrito que permite um grau de introspecção e dados de dados de encaminhamento que são tão limitados que não excedem a funcionalidade real de qualquer coisa que possa ser feita com transações pré-assinadas. A proposta de valor não está em ativar novas funcionalidades por si só, mas melhorar drasticamente as garantias de eficiência, escalabilidade e segurança do que pode ser construído atualmente usando transações pré-assinadas. Isso por si só é um grande benefício para quase todos os protocolos atualmente implantados usando transações pré-assinadas.

Aqui estão alguns dos projetos que demonstram o quão completamente desenvolvido e explorou esse pacto em particular é comparado aos outros:

• Um exemplo de pool de pagamentos básico da Stutxo.
• Uma implementação do CTV Vault de James O’Beirne, que passou a propor Op_vault (que ainda faz uso da CTV).
• Uma porta de prova de conceito da implementação da ARK baseada em transações pré-assinada do segundo por Steven Roose para usar o CTV.
• O idioma da SAPIO, do Jeremy Rubin, um idioma de nível superior para a construção de contratos com a CTV (também apoiando o uso de transações pré-assinadas).
• Timeout Trees, uma proposta para um design de Coinpool muito básico de John Law.
• Numerosos outros protocolos possíveis, como contratos de log discretos otimizados (DLCs), canais de raios não interativos que uma parte pode abrir sem a outra e até mesmo formas descentralizadas para os mineiros se reunirem.

A CTV é uma proposta incrivelmente madura neste momento, com um maior valor agregado e nenhum risco de permitir qualquer coisa que impulsione as preocupações em torno de convênios. Isso não deve ser apenas seriamente considerado seriamente, mas na minha opinião pessoal deveria ter sido ativada anos atrás.