OP_CAT 会发生吗？契约提案刚刚被分配了 BIP 编号 #347。但在深入探讨之前，让我们先探讨一下契约是什么，以及比特币用户为什么需要它们。
比特币是数字电子现金的理想状态吗，还是我们想从链上的货币中获得更多？
比特币脚本的局限性
要理解像 OP_CAT 这样的契约提案，了解比特币脚本目前的基本局限性至关重要。在底层，比特币允许通过定义锁定和解锁资金规则的代码创建基本的智能合约。然而，作为一种编程语言，比特币脚本相当局限于只有在新交易中移动硬币时才会发挥作用的基本逻辑。
如今，在比特币中，没有办法预先配置或规定你的货币的交易路径，或者货币在被锁定时的移动速度（除了使用 PSBT 的黑客工作流程、部分签名的比特币交易，这些交易无法正确包含交易费用、如果未使用则证明删除，或防止以后广播）。
这种简单性虽然是比特币安全模型的核心，但却对脚本语言支持基本智能合约的能力造成了重大限制。
线性执行模型
比特币脚本的一个限制是它的操作模型，其中操作码按顺序执行而没有循环。
从这个 P2PKH 交易的例子中，您可以看到脚本如何线性执行：复制公钥、将其散列到地址、根据锁定脚本验证散列，最后根据公钥检查签名。
没有循环意味着脚本不是图灵完备的，并且一定会终止，从而防止无限循环等可能导致网络停止或显著减慢的问题。虽然这种设计选择允许静态限制资源使用，但它也限制了脚本管理复杂工作流程的能力。
缺乏基本算术
比特币脚本有将近 100 个非平凡操作码，而且有些令人惊讶的是，它无法对堆栈上的对象进行乘法、除法或组合。许多对 OP_CAT 感兴趣的用户都知道，中本聪在 2010 年禁用了比特币中的几个操作码，包括 OP_OR、OP_MUL（乘法）、OP_DIV（除法）和 OP_CAT（连接）等。禁用的操作码被删除，因为它们的原始实现存在可利用的漏洞，可能会危及网络的安全。但是，这些操作码的缺失使得进行基本数学运算变得困难，而这在计算合约中的交易费用等简单场景中可能很有用。
缺乏交易数据可见性
从表面上看，我认为大多数人都认为比特币智能合约能够看到价值金额和交易数据的任何其他部分，因为这些信息已经在区块链上公开可见。但与此假设相反，比特币上的合约无法根据交易数据设置支出条件，因为比特币脚本查看交易数据的能力非常有限。
如果脚本有能力解释交易数据中的更多细节，我们就可以构建更为强大的合约，可以做所有有趣的事情，比如强制执行特定的消费条件，创建多阶段交易，以及启用更高级的安全功能，比如保险库。
我们该怎么办呢？
我们知道比特币有这些限制，多年来，已经讨论了许多不同的提案来引入（或在某些情况下重新引入）此功能。对比特币脚本的更广泛实验，例如 Simplicity 等，旨在提供基于堆栈的约束的替代方案。OP_MULTISHA256、OP_LESS 和 OP_LE32TOLE64 等操作码旨在升级比特币的算术能力。处理自省操作码的 OP_CTV 和 OP_CAT 等提案归类为术语“契约”。
那么智能合约和新期限契约到底有什么区别呢？
智能合约与契约
智能合约是无需中介即可自动执行的资金转移交易。在当今的比特币中，智能合约仅限于使用比特币脚本锁定和解锁比特币的行为。契约旨在通过让用户控制其资金在未来交易中的使用方式来增强比特币的智能合约功能。
通过启用脚本来解释交易数据，我们有效地创建了一种在合约逻辑中使用这些数据的方法。
这些只是契约功能中一些更有趣的内省操作码：
OP_TXHASH：提供交易输入（或输出）的哈希值，并赋予脚本根据交易数据验证和执行条件的能力。
OP_CSFS + OP_CAT：两者结合允许脚本针对任何数据（而不仅仅是交易本身）检查签名。这意味着脚本可以根据交易数据或外部信息验证条件，从而扩大比特币脚本内验证的可能性。
这两个操作码的范围故意设计得比较宽泛，可以实现复杂的验证流程和自省功能。其他操作码的范围则比较狭窄，旨在成为一种更为有限的契约形式。
OP_CHECKTEMPLATEVERIFY (CTV)：允许交易输出嵌入未来支出交易的模板，以更受约束的方式实现契约。
OP_VAULT：启用用于“保险库”的特定形式的契约，让用户指定交易目的地，但除了延迟之后实际上不能移动硬币。
然后还有 OP_CAT 本身，它不直接是一个自省操作码……
OP_CAT：允许脚本连接堆栈上的两个元素，这对于组合脚本内的不同信息很有用。
OP_CAT 似乎没有任何内省能力，那么这里发生了什么？
OP_CAT：揭示所有可能性
交易自省
2021 年，Andrew Poelstra 在一篇博客文章中介绍了 OP_CAT 自省技巧。他提供了具体的例子，但假定读者已经了解了类似的技术。在这里，我将简化该解释，以便更好地理解。
在比特币脚本中，只有三个主要操作码允许您检查交易数据：CHECKLOCKTIMEVERIFY、CHECKSEQUENCEVERIFY 和 CHECKSIG。此外，还有 CHECKSIGVERIFY、CHECKSIGADD、CHECKMULTISIG 和 CHECKMULTISIGVERIFY 等变体，它们本质上是 CHECKSIG 的细微变体。前两个仅让您查看检查是否已验证，提供的功能相当有限。CHECKSIG 类似，但这里的区别在于它允许您获取堆栈上的签名和公钥。很有趣。
传统上，我们认为连接是将两个项目连接在一起的函数，但我们也可以用它来分离或分割一个项目，在本例中，将签名拆分为 (r, s) 对。
我们如何从 OP_CAT 中得出 OP_SPLIT 功能？
“如果您有一些大对象，您可以将其拆分成两部分，方法是让用户花时间提供两个部分。您可以将它们组合在一起并检查相等性。您始终可以通过这种方式反转每个操作。使用 CAT 本身，您可以拆分签名。” — Andrew Poelstra，TABConf 2021
这里发生了什么事？
通过要求用户提供签名、公钥和交易，您可以将签名拆分成各个组成部分，然后根据交易数据单独检查每个部分。此技术可以视为一种拆分或合并的形式，因为它可以验证签名和公钥确实是有效交易的组成部分。
这一切如何让我们进行反省？
“在 Taproot 中，我们使用 OP_CAT 和 Schnorr 签名验证操作码进行 Schnorr 签名，事实证明，可以得到一种非递归契约的形式，从中你可以得到一个交易哈希。这甚至不像是一个有趣的混乱交易哈希，而是堆栈上所有交易数据的字面 SHA2 哈希。” — Andrew Poelstra，TABConf 2021
Poelstra 继续演示如何获取堆栈中交易输入或输出的 SHA2 哈希。我们在这里跳过月球数学，但其含义是，使用 OP_CAT，我们可以将交易的某些部分作为解锁脚本的要求进行约束。我们可以约束该交易的发送地址或发送值，其中交易哈希作为解锁它的密钥。
保险库
使用相同的技术，我们可以进行交易自省，并快速获得保险库的基本版本。按照 Poelstra 博客中概述的逻辑，一位名叫 Rijndael 的开发人员在他的 Purrfect Vaults 实现中证明了我们可以仅使用 OP_CAT 做到这一点。
“在堆栈上重建 TXID 来检查之前的交易实际上比我想象的要容易。”—— Rijndael
通过保险库，用户可以指定他们的资金必须存入的下一个地址，从而在密钥泄露的情况下提供资金恢复机制，并减少私钥被盗的动机。
脚本的 Merkle 树
在当今的比特币中，Merkle 树是用于数据验证、同步以及或多或少将区块链的交易和区块“链接”在一起的数据结构。OP_CAT 操作码允许连接两个堆栈变量，当与公钥的 SHA256 哈希一起使用时，它有助于为脚本提供简单的 Merkle 树验证过程。这种方法最初由 Pieter Wuille 于 2015 年提出，并已在 Liquid 网络中成功实施。
想象一个充满各种支出条件的树结构，例如哈希原像、时间锁和公钥，称为树签名。
树签名
OP_CAT 支持创建树签名，其特点如下：
“…提供一个多重签名脚本，其大小可以是公钥数量的对数，并且可以对超过 n-of-m 的支出条件进行编码。例如，小于 1KB 的交易可以支持具有一千个公钥的树形签名。这还可以实现通用的逻辑支出条件。” — BIP 作者 Ethan Heilman 在 bitcoin-dev 邮件列表中
这将能够验证树中任何散列内容，维护数据完整性和可信度，而不会给区块链添加不必要的体积或膨胀。
这一切有什么有趣的呢？
递归契约
如果您有能力检查交易并对其某些部分应用约束，则可以设置通过多个交易延续的条件，从而有效地创建持续的限制链。这个概念称为递归契约。OP_CAT 是一个独特的提议，因为它只用 10 行新代码就赋予了我们如此强大的功能。它能够解决我们在文章开头提到的所有三个初始限制：交易数据可见性、更好的数学功能及其线性执行模型。
虽然 OP_CAT 乍一看似乎很简单，但如果加以创造性利用，它就会释放出巨大的潜力。它可以作为远远超出本文讨论范围的更多功能的构建块，例如后量子 Lamport 签名。
这安全吗？
在最初删除 OP_CAT 之前，当它与 OP_DUP（重复）结合使用，并重复用于在堆栈上复制最初为 1 字节的值时，内存使用量可能会激增。由于内存消耗增加，这可能会被用作拒绝服务 (DoS) 攻击。新提案通过对堆栈元素施加 520 字节的限制，轻松地防止了这种攻击。
合同永远有效是否存在危险？
如果我们这样想，那么 OP_CAT 是否会改变脚本的执行模型，意味着它不再静态地限制其资源使用（作为脚本大小的线性函数）？不是的。
契约是否会在比特币的基础上为其他货币创造一个市场？
如果你有一个递归契约，那么从技术上讲，你可以构建复杂的第 2 层应用程序，包括 NFT、去中心化交易所和量子猫。然而，这样做并不是一件容易的事。很难看到任何严肃的市场这样做。
你能通过使用 CAT 永久地“污染”硬币吗？
对于彩色币和 NFT，发行这些资产的用户实际上是“烧掉”了一个聪，以一种表示对“第 2 层”资产所有权的方式对其进行标记。这个过程被称为“污染”币。但只有币的所有者才能标记他们的币，比特币钱包将不再识别它（除非作者明确添加代码来实现这一点）。由此产生的币不会被比特币钱包接受。它们可能会被 cryptocat 钱包或类似的东西接受，但这与大多数比特币用户无关。
这会造成比特币的 MEV 问题吗？
比特币和以太坊之间的一个关键区别是交易可见性。与以太坊不同，合约的各个方面不一定都是透明的，这意味着比特币矿工无法看到内部合约状态并抢先交易。
具有经济意识的比特币用户对 OP_CAT 的主要关注点是矿工可提取价值 (MEV) 的潜力。正如我在之前关于这个主题的帖子中更广泛讨论的那样。许多用户担心，如果我们在技术上使第 2 层合约成为可能，MEV 将变得不可避免。但这是真的吗？具体来说，比特币上第 2 层代币的技术可行性是否意味着它们必然会被创建和采用？
你可以想象建立简单的掉期合约或相对低效的 NFT，但建立像 DEX 这样复杂的东西并带有自动做市商的东西似乎极不可能，而且尽管具有“技术可能性”，但我们从未在 Liquid 上看到过这种情况。
那么OP_CAT真的完美吗？
几乎不可能，离得还很远。有些人很想看到递归契约，而其他人则根本不想看到比特币发生任何变化。
比特币支持者中有一派人，即“僵化主义者”，主张保持比特币的现状，并对任何协议升级持怀疑态度。他们特别担心，引入契约等重大变化可能会破坏网络的去中心化。他们的论点取决于这样的信念：最好坚持比特币的最初愿景。讽刺的是，OP_CAT 最初是比特币的一部分，这引发了反驳。一些人认为，恢复 OP_CAT 实际上可以让比特币与中本聪的最初愿景保持一致。
如果你想了解递归契约可以实现的一些安全功能，OP_CAT 会很不错，但绝对不如成熟的 Lisp 式脚本语言好。问题在于，这将对比特币产生巨大影响，不太可能在短期内站稳脚跟。
或者，你站在另一边，更喜欢 OP_CTV 或 OP_VAULT 等非递归的简单性。非递归契约更简单，更容易推理，而且没有创建不受控制的约束链的风险。
如果某种版本的递归契约不可避免会怎样？
多年来，开发人员注意到几乎任何交易验证逻辑的扩展都可以用来模拟 OP_CAT 的功能。
在脚本世界中，根据堆栈元素的大小，有两个领域。对于大于 4 个字节的堆栈元素，您可以比较相等性、将其解释为密钥签名或对其进行哈希处理。对于小于或等于 4 个字节的堆栈元素，您可以将它们视为对象来执行算术或分支。使用在 BitVM 上运行的 RISC-V 处理器，您几乎可以做任何事情。任何允许您模拟 OP_CAT、分解堆栈元素或将它们连接在一起的东西都会将这两个领域结合在一起，这样您就可以使用脚本“做任何事情”。
像 Andrew Poelstra 这样的研究人员希望我们能够使用几乎任何新的操作码来执行递归契约。如果这是真的，那么这将是努力寻找一种做好它们的方法的理由。
OP_CAT 是契约前进的可能道路吗？
如果契约不仅有趣，而且不可避免，那么我们如何确保它以这样的方式实施，让更多的比特币用户像中本聪最初设想的那样进行无需信任的发送？虽然僵化主义者仍然存在分歧，但 OP_CAT 仍然继续成为契约辩论中的有力竞争者。
OP_CAT 不是最优雅的凿子，但它具有最佳的功能与复杂性比率，可以让开发人员创造出一些令人惊叹的新功能。
这是 Kiara Bickers 的客座文章。表达的观点完全是他们自己的观点，并不一定反映 BTC Inc 或 Bitcoin Magazine 的观点。
来源：比特币杂志
文章 OP_CAT：契约的完美解决方案？首先出现在 Crypto Breaking News 上。
