Este é o quinto 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_CAT, apresentado para reativação em Tapscript por Ethan Heilman e Armin Sabouri no BIP 347, não é uma aliança. Foi um código de opção que foi originalmente incluído no primeiro lançamento do Bitcoin para manipular elementos de dados na pilha. Foi desativado em 2010 com o lançamento do Bitcoin 0.3.10, juntamente com vários outros códigos de operações devido a preocupações de negação de ataques de serviço que poderiam travar nós. Um limite máximo global de 520 bytes para qualquer item individual na pilha durante a execução de um script também foi adicionado.
Você já deve ter um entendimento básico de como funciona a avaliação do script na pilha e as peças básicas de uma transação de bitcoin, portanto, não há realmente muito pré-requisito explicando necessário para o OP_CAT.
Embora o OP_CAT possa não ser um pacto por si só, ele pode emular convênios devido a uma peculiaridade na maneira como as assinaturas da Schnorr funcionam. Este é um tópico bastante profundo, totalmente explicado aqui por Andrew Poelstra da BlockStream, então ficarei com uma visão de alto nível. Cada curva elíptica tem um ponto de gerador, que é essencialmente “0”, usado na matemática da curva elípica para geração e assinatura das chaves. Com a Schnorr, você pode assinar usando o ponto do gerador como uma chave e dar ou pegar alguns bytes que você deve assinar repetidamente para acertar, a assinatura resultante é na verdade o mesmo hash da transação que você assinou.
Deixe de lado a mecânica de como isso funciona matematicamente por enquanto e lembre -se de que essas assinaturas “estranhas” permitem obter as transações atuais TXID na pilha.
Como funciona o op_cat
Op_cat pega os dois principais itens de dados na pilha e os concatena juntos. Portanto, se os dois principais itens da pilha forem “1” e “2”, o Op_Cat remove os dois e depois coloca “12” no topo da pilha. É isso.
Para que é útil op_cat
Ok, então qual é o problema? Por que todo mundo está enlouquecendo sobre Op_cat, embora seja tão simples a explicação de como funciona nem sequer levou um parágrafo completo para escrever?
Duas razões, embora dada a natureza do op_cat, não posso garantir que essas sejam as duas únicas razões. Op_cat permite a construção e verificação de árvores de merkle diretamente na pilha, o que abre a porta para algum comportamento e funcionalidade interessantes. Também permite a emulação de convênios que possibilitam a introspecção granular completa devido às assinaturas de Schnorr “estranhas” mencionadas acima.
A verificação à prova de Merkle é um componente essencial da torre de torneira, mas a maneira como é implementada a verificação de árvores de merkle ocorre apenas no contexto de verificar se um caminho de gastos com Tapscript está comprometido na chave pública da raiz do script de saída da moeda gasta. Taproot não suporta verificação genérica à prova de merkle.
Op_cat permite isso de uma maneira totalmente genérica. Simplesmente fornecer os (s) folhas de hash (s) e, em seguida, os nós de hash interiores na ordem certa e chamar Op_cat sucessivamente permitirão reconstruir um hash de raiz de merkle e comparar com um hash predefinido no script. Você pode fazer isso para fornecer caminhos de retirada unilateral para UTXOs compartilhados, como no CATVM, você pode tornar as transações dependentes de outras transações incluídas em um bloco com trabalho válido, pode tornar uma transação dependente de praticamente qualquer condição que possa ser verificada com uma prova de merkle.
Agora, para a emulação da aliança que permite a introspecção total. O que você está tentando fazer é garantir que uma transação tenha que ter certas características a serem válidas. Lembre -se agora de que a assinatura “estranha” recebe o hash da transação na pilha. Uma assinatura da transação não é realmente feita durante a transação bruta, é feita sobre seu hash. Isso nos permite fazer algo interessante.
Você pode construir scripts muito complicados e complicados usando o OP_CAT para levar as peças brutas individuais da transação como parte da testemunha e os reunir lentamente na pilha com OP_CAT. Ao longo do caminho, as peças individuais da transação podem ser verificadas contra hashes predefinidos, apenas o hão e usando o OP_EQUAL. No final do script, você tem a transação completa na própria pilha e pode anexar os dados necessários e, em seguida, o hash, mais uma vez comparando -os com OP_EQUAL, desta vez com a assinatura “estranha”. Se esse cheque passar, uma verificação normal poderá ser executada e, desde que a assinatura “estranha” fosse feita com a transação sendo gasta, tudo é executado como válido.
As verificações op_equal de peças individuais da transação ao longo do caminho garantem que essas peças da transação são exatamente o que deveriam ser. Se algum deles falhar, a transação será inválida. Isso aplica os convênios emulados. No final, se o hash da transação foi construído com o OP_CAT e a correspondência de assinatura “estranha ', o verificação final garante que a transação construída com OP_CAT e verificada contra a aliança emulada corresponda à transação real gasta na época.
Pensamentos finais
Op_cat Blows abre as portas de introspecção e dados para a frente que transportam completamente. A introspecção pode ser realizada em qualquer grau granular desejado, com cada campo individual da transação sendo capaz de se comprometer independentemente. Permite todos os mesmos recursos introspectivos que o TXHASH, e mais alguns.
A capacidade de verificar as provas genéricas do Merkle também é uma funcionalidade poderosa, mas questiona como esse recurso será usado e que tipo de incentivo que poderia criar. Os scripts de Bitcoin podem ser construídos exigindo que alguma transação seja feita em sistemas de blockchain externos, desde que usem árvores de merkle construídas com as funções de hash disponíveis no script Bitcoin.
Embora o Op_cat não seja um pacto, permite a emulação completa de convênios com uma pegada de blockchain muito menos eficiente (e potencial para os desenvolvedores cometem erros e queimam dinheiro). É uma proposta que, apesar de ser incrivelmente simples, deve ser abordada com cautela, dado o enorme espaço de design que ele abre.
Fonte: bitcoinmagazine.com
