Este é o segundo artigo em um série Mergulhar profundamente em propostas individuais de aliança que atingiram um ponto de maturidade que merecem um detalhamento aprofundado.
Checksigfromstack (CSFS), apresentado por Brandon Black e Jeremy Rubin com BIP 348, não é uma aliança. Como eu disse no artigo introdutório desta série, algumas das propostas que eu cobriam não são convênios, mas sinergizam ou inter -relacionam com elas de alguma forma. CSFS é o primeiro exemplo disso.
O CSFS é um código de opção muito simples, mas antes de passarmos como funciona, vamos ver o básico de como um script de bitcoin realmente funciona.
O script é uma linguagem baseada em pilha. Isso significa que os dados são “empilhados” juntos um no outro na pilha e operados removendo um item da parte superior da pilha para operar com base no que um opcode faz, retornando os dados ou o resultado dele para o topo da pilha.
Existem duas partes de um script quando é executado e verificado, a “testemunha” fornecida para desbloquear o script e o script incluído na saída que está sendo gasta. O script de testemunha/desbloqueio é “adicionado” ao lado esquerdo do script de travamento e, em seguida, cada elemento é adicionado a (ou opera) a pilha, uma a uma da esquerda para a direita. Veja este exemplo (o ““|”Marca a fronteira entre a testemunha e o script):
1 2 | On_add 3 on_equal
Este script de exemplo adiciona o valor “1” à pilha e, em seguida, o valor “2” em cima disso. Op_Add pega os dois principais elementos da pilha e os adiciona, colocando o resultado de volta à pilha (então agora tudo o que está na pilha é “3”). Outro “3” é então adicionado à pilha. O último item, op_equal, pega os dois principais itens da pilha e retorna um “1” à pilha (1 e 0 pode representar verdadeiros ou falsos, bem como números).
Um script deve terminar com o último item na parte superior da pilha sendo verdadeiro, caso contrário, o script (e a transação executando -o) falha e é considerado um consenso inválido.
Este é um exemplo básico de um script de pagamento a pubkey-hash (P2PKH), ou seja, os endereços Legacy que começam com um “1”:
Primeiro, a assinatura e a chave pública são adicionadas à pilha. Em seguida, o DUP é chamado, que pega o item superior da pilha e o duplica, devolvendo -o ao topo da pilha. O hash160 pega o item de pilha superior (a duplicata de chave pública), hashes e depois o retorna ao topo da pilha. O hash da chave pública do script é colocada em cima da pilha. A Equalverify funciona da mesma forma que igual, ele pega os dois itens de pilha superior e retorna um 1 ou 0 com base no resultado. A única diferença é o Equalverify também é executado após igual, o que falha na transação se o item de pilha superior não for 1 e também remover o item de pilha superior. Finalmente, o checksig é executado, que agarra os dois principais itens da pilha, assumindo que eles sejam uma assinatura e um pubkey e verifica a assinatura implicitamente contra o hash da transação que está sendo verificada. Se for válido, coloca um 1 em cima da pilha.
Como funciona o CSFS
O Checksig é um dos códigos OPCs mais usados no Bitcoin. Toda transação, quase sem exceções, faz uso desse código de operação em algum momento de um de seus scripts. A verificação de assinatura é um componente fundamental do protocolo Bitcoin. O problema é que quase não há flexibilidade em termos de que a mensagem você está verificando a assinatura. O Checksig verificará apenas uma assinatura em relação à transação que está sendo verificada. Há alguma flexibilidade, ou seja, você pode decidir com algum grau de liberdade a que parte da transação a assinatura se aplica, mas é isso.
O CSFS pretende alterar isso, permitindo que uma assinatura seja verificada contra qualquer mensagem arbitrária que seja empurrada diretamente para a pilha, em vez de ser limitada à verificação de assinaturas contra a própria transação. O código OPCILE segue uma estrutura operacional muito básica:
A assinatura e a mensagem são descartadas na parte superior da pilha, depois a chave pública em cima deles e, finalmente, o CSFS conquista os três principais itens da pilha, assumindo que eles sejam a chave pública, a mensagem e a assinatura de cima para baixo, verificando a assinatura em relação à mensagem. Se a assinatura for válida, um 1 será colocado na pilha.
É isso. Uma variante simples do checksig que permite que os usuários especifiquem mensagens arbitrárias em vez de apenas a transação de gastos.
Para que os CSFs são úteis para
Então, para que exatamente isso é bom? Qual é a utilidade de verificar uma assinatura contra uma mensagem arbitrária na pilha, em vez de contra a transação de gastos?
Em primeiro lugar, em combinação com a CTV, ele pode fornecer uma funcionalidade equivalente a algo que os desenvolvedores de raios queriam desde o início, assinaturas flutuantes que podem anexar a diferentes transações. Isso foi originalmente proposto como uma nova bandeira de Sighash para assinaturas (o campo que determina a que parte de uma transação um assinatura se aplica). Isso foi necessário porque uma assinatura da transação cobre o ID da transação da transação que criou a saída gasta. Isso significa que uma assinatura é válida apenas para um gasto de transação que exato saída.
Este é um comportamento desejado para raios, porque nos permitiria acabar com as penalidades do canal. Todo raio anterior precisa de uma chave de penalidade e transação para garantir que sua contraparte do canal nunca use nenhum deles para tentar reivindicar fundos que não possuem. Se eles tentarem, você pode reivindicar todo o seu dinheiro. Uma funcionalidade superior seria algo que permite que você simplesmente “anexe” a transação de estado atual a qualquer anterior para interromper a tentativa de roubo, distribuindo fundos corretamente, em vez de confiscá -los.
Isso pode ser realizado com um script básico que leva um hash de CTV e uma assinatura sobre ele que é verificada usando o CSFS. Isso permitiria que qualquer hash de transação assinado por essa chave do CSFS gastar qualquer saída criada com este script.
Outro recurso útil é a delegação de controle de um UTXO. Da mesma forma que qualquer hash da CTV assinado por uma chave CSFS pode valeramente gastar um UTXO com um script projetado para isso, outras variáveis podem ser transmitidas para o script a ser verificado, como uma nova chave pública. Um script pode ser construído que permita que uma chave de CSFS assine qualquer Public Key, que pode ser validado usando o CSFS e usado para uma validação normal de verificação. Isso permitiria que você delegue a capacidade de gastar um UTXO para qualquer outra pessoa sem ter que movê-lo na cadeia.
Por fim, em combinação com CAT, os CSFs podem ser usados para compor funcionalidade intropecção muito mais complexa. Como veremos mais adiante na série, o CSFS não é realmente necessário para imitar nada desse comportamento mais avançado, pois o gato sozinho é capaz de fazê -lo.
Pensamentos finais
O CSFS é um código de opção muito básico que, além de oferecer uma funcionalidade útil simples por si só, compõe muito bem com os códigos de aliança mais simples para criar funcionalidade muito útil. Enquanto o exemplo acima sobre as assinaturas flutuantes referenciam especificamente a rede Lightning, as assinaturas flutuantes são um primitivo geralmente útil aplicável a qualquer protocolo construído sobre o Bitcoin que use transações pré-assinadas.
Além das assinaturas flutuantes, a delegação de script é um primitivo muito útil que generaliza muito além do controle delegador do UTXO para uma nova chave pública. A mesma capacidade básica de “desvendar” variáveis após o fato em um fluxo de validação de script pode se aplicar a qualquer coisa, não apenas às chaves públicas. Valores de timelock, prematuras de hashlock etc. Qualquer script que coda uma variável para verificar agora pode ter esses valores adicionados dinamicamente após o fato.
Além disso, o CSFS é uma proposta muito madura. Possui uma implementação que está ativa na rede e elementos líquidos (o líquido CodeBase usa) desde 2016. Além disso, o Bitcoin Cash possui uma versão desde 2018.
O CSFS é uma proposta muito madura que remonta conceitualmente quase tanto quanto eu estive nesse espaço, com várias implementações maduras e casos de uso muito claros para os quais pode ser aplicado.
Fonte: bitcoinmagazine.com
