深入研究OP_CAT：比特币脚本的新时代

这是一系列深入研究单个盟约提案的第五篇文章，这些提案已达到了成熟的点，值得深入分解。

This is the fifth article in a series deep diving into individual covenant proposals that have reached a point of maturity meriting an in-depth breakdown.

这是一系列深入研究单个盟约提案的第五篇文章，这些提案已达到了成熟的点，值得深入分解。

OP_CAT, put forward for reactivation in tapscript by Ethan Heilman and Armin Sabouri in BIP 347, is not a covenant. It was an opcode that was originally included in the first release of Bitcoin for manipulating data elements on the stack. It was deactivated in 2010 with the release of Bitcoin 0.3.10 along with a number of other opcodes due to concerns of denial of service attacks that could crash nodes. A global maximum limit of 520 bytes for any individual item on the stack while executing a script was also added.

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

You should already have a basic understanding of how script evaluation on the stack works, and the basic pieces of a bitcoin transaction, so there isn’t really much pre-requisite explaining necessary for OP_CAT.

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

While OP_CAT may not be a covenant in and of itself, it can emulate covenants due to a quirk in how Schnorr signatures work. This is a pretty in depth topic, fully explained here by Andrew Poelstra from Blockstream, so I’ll just stick with a high level view. Every elliptic curve has a generator point, which is essentially “0”, that is used in the elliptic curve math for key generation and signing. With Schnorr, you can sign using the generator point as a key, and give or take a few bytes that you have to sign repeatedly to get right, the resulting signature is actually the same hash of the transaction you signed.

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

Set aside the mechanics of how that works mathematically for now, and just remember for later that these “weird” signatures allow you to get the current transactions TXID on the stack.

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

How OP_CAT Works

OP_CAT的工作原理

OP_CAT takes the top two data items on the stack and concatenates them together. So if the top two items on the stack are “1” and “2”, OP_CAT removes both of them and then puts “12” on top of the stack. That’s it.

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

What Is OP_CAT Useful For

什么是op_cat有用的

Okay, so what’s the big deal? Why is everyone freaking out about OP_CAT even though it’s so simple the explanation of how it works didn’t even take a full paragraph to write.

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

Two reasons, although given the nature of OP_CAT I can give no guarantees these are the only two reasons. OP_CAT allows the construction and verification of merkle trees directly on the stack, which opens the door to some interesting behavior and functionality. It also allows emulation of covenants enabling full granular introspection due to the “weird” Schnorr signatures mentioned above.

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

Merkle proof verification is a key component of Taproot, but the way it is implemented merkle tree verification only occurs in the context of verifying that a tapscript spending path is committed to in the root Schnorr public key in the output script of the coin being spent. Taproot does not support generic merkle proof verification.

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

OP_CAT allows this in a totally generic manner. Simply providing the leaf hash(es) and then interior hash nodes in the right order and calling OP_CAT successively will allow you to reconstruct a merkle root hash, and compare against a pre-defined hash in the script. You could do this to provide unilateral withdrawal paths for shared UTXOs like in CatVM, you could make transactions dependent on other transactions having been included in a block with valid work, you can make a transaction dependent on pretty much any condition that can be verified with a merkle proof.

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

Now, for the covenant emulation that enables full introspection. What you are trying to do is ensure that a transaction has to have certain characteristics to be valid. Remember now that the “weird” signature gets the hash of the transaction on the stack. A transaction signature isn’t actually done over the raw transaction, it’s done over its hash. This allows us to do something interesting.

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

You can construct very complicated and convoluted scripts using OP_CAT to take the individual raw pieces of the transaction as part of the witness, and slowly put them together on the

您可以使用op_cat构建非常复杂和复杂的脚本，以将交易的各个原始部分作为证人的一部分，然后慢慢将它们放在一起