这是第五篇深入研究各个盟约提案，这些提案已达到了成熟度，值得深入崩溃。

在Bip 347中，Ethan Heilman和Armin Sabouri在Tapscript中提出重新激活，这不是盟约。这是一个最初包含在比特币版本中的OPCODE，用于操纵堆栈上的数据元素。它在2010年与其他许多Opcodes一起停用，因为担心拒绝可能会崩溃节点的服务攻击。还添加了执行脚本时堆栈上任何单个项目的全局最大限制为520个字节。 

您应该已经对堆栈上的脚本评估以及比特币交易的基本部分有了基本的了解，因此OP_CAT确实没有太多的先决条件解释。 

虽然OP_CAT本身可能不是盟约，但由于Schnorr签名的工作方式，它可以模仿盟约。这是一个深入的主题，由Blockstream的Andrew Poelstra完全解释，因此我将坚持高水平的视野。每个椭圆曲线都有一个发电机点，本质上是“ 1”，用于椭圆曲线数学中用于密钥生成和签名。使用Schnorr，您可以使用发电机点作为键进行签名，并给出或采用几个字节，您必须重复签名才能正确，实际上，签名实际上与您签名的交易的哈希相同。 

搁置了现在的数学工作方式的机制，然后记住以后要记住，这些“怪异”签名使您可以在堆栈上获得当前的交易TXID。 

 OP_CAT的工作原理

OP_CAT将堆栈上的两个数据项占据了顶部，并将它们串联在一起。因此，如果堆栈上的前两个项目是“ 1”和“ 2”，则OP_CAT将其删除两个，然后将“ 12”放在堆栈顶部。那。 

什么是op_cat有用的

好吧，这大不了吗？为什么每个人都对op_cat感到恐惧，即使它如此简单，其工作方式的解释甚至都没有花费完整的段落写作？ 

尽管鉴于op_cat的性质，但我不能保证这两个原因是唯一的两个原因。 OP_CAT允许直接在堆栈上构建和验证Merkle树，这为一些有趣的行为和功能打开了门。由于上述“怪异”的schnorr签名，它还允许模仿盟约，从而实现全颗粒状的内省。 

Merkle证明验证是Taproot的关键组成部分，但是它实现了Merkle树验证的方式仅在验证tapscript支出路径的背景下发生在root Schnorr公共密钥中的root Schnorr公共密钥中，在所花费的硬币的输出脚本中。 Taproot不支持通用的Merkle证明验证。 

OP_CAT允许完全通用的方式。只需提供正确的顺序提供叶子哈希（ES），然后提供内部哈希节点，然后依次调用OP_CAT，就可以使您重建一个默克尔根哈希，并与脚本中的预定的哈希进行比较。您可以这样做以提供共享UTXOS的单方面撤回路径，您可以将交易取决于已包含在有效工作的块中的其他交易，您几乎可以根据任何可以通过Merkle证明进行验证的交易。 

现在，对于能够充分自省的盟约仿真。您要做的是确保交易必须具有某些特征才能有效。现在请记住，“怪异”签名获得了堆栈上的交易哈希。实际上，在原始交易中实际上并未完成交易签名，而是通过其哈希进行的。这使我们能够做一些有趣的事情。 

您可以使用OP_CAT构建非常复杂且令人费解的脚本，以将交易的各个原始部分作为证人的一部分，并慢慢将它们与OP_CAT一起放在堆栈上。一路上，可以通过has hass和使用OP_Equal来检查交易的各个部分。在脚本的末尾，您可以在堆栈本身上进行完整的交易，并可以将必要的数据附加到它上，然后将其放置，然后再次将其与OP_Equal进行比较，这次与“怪异”签名。如果该检查通过，则可以运行正常的检查，并且只要在交易中进行“怪异”签名，所有内容都将执行为有效。 

沿途交易的单个部分的OP_E均等检查确保交易的那些部分正是应有的。如果其中任何一个未能进行验证，则交易无效。这实施了模拟盟约。最后，如果通过OP_CAT构建的交易哈希和“怪异”签名匹配，则最终检查可以确保使用OP_CAT构建的事务并针对模拟盟约进行检查，以匹配当时花费的实际交易。 

结束思想

OP_CAT打开内省和正向数据完全携带的门。内省可以达到所需的任何颗粒度，而交易的每个字段都可以独立承诺。它具有TXHASH具有的所有相同内省功能，然后是一些。 

验证通用默克尔证明的能力也是一个强大的功能，但是质疑如何使用该功能，以及可以创造哪种类型的激励措施。只要使用使用比特币脚本可用的哈希功能构建的默克尔树，就可以在外部区块链系统上构建比特币脚本，以便在外部区块链系统上进行一些交易。 

虽然OP_CAT本身不是盟约，但它允许完全仿真具有效率较低的区块链占地面积（以及开发人员犯错误和赚钱的潜力）。提出的建议是，尽管它本身非常简单，但应该谨慎对待它的大量设计空间。