13 行代码帮助比特币实现智能合约？读懂 OP_CAT 软分叉

撰文：Jaleel，BlockBeats

比特币代码库中，一个曾经被中本聪删除被历史尘封已久的操作码「OP_CAT」或将「复活」。

围绕着 OP_CAT 操作码，比特币 NFT 项目 Taproot Wizards 推出了新系列 NFT Quantum Cats 引起热社区议。尽管 OP_CAT 这一称呼并非指向我们熟悉的「猫」，但 Taproot Wizard 却用了猫的形象发售了一款名为 Quantum Cats 的新 NFT，利用模因文化，帮助 OP_CAT 造势。

OP_CAT，这个一度被中本聪从比特币脚本语言中移除的操作码，如今被重新拿到了台面上讨论，一些比特币开发者想要「复活」这个操作码，并通过 13 行代码的软分叉，为比特币实现智能合约做出铺垫。在比特币开发者的推动和以猫的模因形象造势下，关于 OP_CAT 的热度和讨论达到了新的高度。

「复活」被中本聪删除的操作码

操作码（Opcodes），亦称为指令或函数，是构成比特币脚本语言的基本组成元素。历史上，由于对客户端实现可能存在的漏洞的担忧，比特币早期版本中的某些操作码被移除，OP_CAT 操作码就是其中之一。

OP_CAT 起初是比特币官方命令集的一部分，允许进行字符串的连接操作，将两个元素拼接成一个。但因为在 OP_LSHIFT 等操作码中发现的严重漏洞可能导致任何比特币节点崩溃，同时担心 OP_CAT 操作码可能导致堆栈元素指数级增长，从而可能导致内存使用量与脚本大小呈指数关系增长。

因此中本聪出于谨慎，在 2010 年 8 月 15 日将 OP_CAT 被移除。这些被移除的操作码通常被称为「禁用」，但这种说法并不准确，因为它们从协议中被彻底删除，使得任何使用比特币的人都无法使用这些操作码。

2023 年 10 月，Bitcoin Core 开发者 Ethan Heilman 和 Botanix Labs 首席软件工程师 Armin Sabouri 联合发布了一份比特币改进提案（BIP）草案，名为「OP_CAT」，让这个讨论到了一个新的高度。

这份草案，仅包含简洁的 13 行代码，却携带了明确直观的功能性质，定义了一个新的 tapscript 操作码，允许在堆栈上串联两个值。此代码实现的灵感明显来自原始被删除的 OP_CAT。

「复活」的条件已经满足

至于为什么一个被中本聪删除的操作码，如今却有开发者希望能恢复，这份 BIP 草案中的动机部分做出了一些详细解释：这主要是基于对内存使用的考量，OP_CAT 使得脚本构造的内存使用量可能与脚本本身的大小呈指数级增长。具体来说，一个简单的脚本，仅通过将一个 1 字节的值推入堆栈，接着利用 OP_DUP 操作码进行复制，再通过 OP_CAT 操作码进行 40 次串联，便可能导致堆栈值膨胀至超过 1TB 的庞大规模。

尽管如此，随着时间的推进和技术的发展，这一问题已不再是障碍。在 tapscript 的架构之下，一个明确的规则被制定，即堆栈元素的大小被严格限制在 520 字节以内。这一改变有效地解决了 OP_CAT 可能引发的内存使用问题，为其「复活」和整合提供了可能性。

由此可见，OP_CAT 再次被拿出来讨论并考虑恢复使用，主要是因为它在构建更复杂和功能强大的脚本方面有潜在的价值。此外，一些原因和变化已经满足「复活」的条件，其中包括：

1. 高级智能合约和协议的需求：随着比特币生态系统的发展，对更高级和复杂的智能合约和协议的需求增加了。OP_CAT 通过允许在堆栈上组合对象，增加了 tapscript 的表达力和功能。例如，它可以用于构建和评估默克尔树和其他哈希数据结构，支持树签名、后量子 Lamport 签名、非抵赖合约、保险库等功能。

2. 其他链上的成功案例：一些比特币分叉，如比特币现金（Bitcoin Cash）和侧链 Liquid，已经重新启用了 OP_CAT，并用它实现了代币的创建和管理、支付通道以及在区块链上嵌入和检索数据的方法。这表明在适当的环境和限制下，OP_CAT 可以安全有效地使用。

3. 量子安全性的探索：有研究提出，如果能够使用 OP_CAT 之类的操作，结合 Lamport 签名等技术，可以构建量子安全的比特币交易和协议。这种探索对于提高比特币系统的未来安全性具有潜在价值。

4. 社区和技术发展：比特币社区和技术的持续发展促使人们重新考虑和评估以前的决定。随着对比特币协议更深入的了解和新技术的出现，之前被认为有问题或不适用的功能可能会在新的上下文中找到安全和有用的应用场景。

软分叉，谈何容易

在技术层面上，几乎鲜有其他比特币提案像 OP_CAT 这般易于解读和理解。但 OP_CAT 操作码将通过重新定义操作码 OP_SUCCESS126 的软分叉激活，显然这并不是一件易事。

回顾比特币近来的一次软分叉发生在三年前，因为激活了 Taproot，从而帮助 Ordinals 的诞生铺平了道路。

比特币社区高度重视共识和透明度，任何重大的代码变更都会在社区中广泛讨论和审查，包括软分叉。一段代码要被合并到比特币的代码库中，需要经过一个严格和详细的流程，这个流程确保了提案的质量和社区的共识。以下是这一过程的主要步骤：

1.编写提案和代码：首先，开发人员需要编写一个详细的提案文档。这个文档应该清楚地描述提案的动机、技术细节、影响评估以及任何潜在的问题或挑战。

2. 社区讨论：代码提案被提交给比特币社区后，社区成员（包括开发者、矿工、投资者和用户）会对其进行讨论和审查。这个阶段是确保提案可行性和收集反馈的关键。

3. 修改和改进：根据社区的反馈，代码的作者可能需要对提案进行修改和改进。

4. 投票，达成共识：对于一些重要的改进（尤其是那些涉及到比特币协议本身的改变），需要社区成员达成一定程度的共识。这通常涉及到矿工的支持，他们需要通过在他们挖掘的区块中包含特定信号来表明他们支持该提案。

5. 代码实现：一旦达成共识，代码将由 Bitcoin Core 开发者团队审核。这个步骤需要确保代码的质量和安全性。

6. 合并到代码库：审核通过后，代码将被合并到比特币的官方代码库中。

7. 部署和激活：新的代码需要被矿工和节点运营者部署到他们的系统中。对于协议层面的改变，通常有一个激活阈值，只有当足够多的网络参与者升级到新版本时，改进才会生效。

显然，OP_CAT 软分叉的实现，还处在非常早期的阶段，距离编写 BIP 草案才过了不到四个月时间，目前 BIP 编号都还没有确定，还处于第一阶段编写提案和代码和第二阶段包括开发者和用户在内的社区讨论环节。

比特币开发者们怎么说

我们先特别关注一下近年来比特币开发者对 OP_CAT 的讨论。

尽管 OP_CAT 操作码被删除，但 OP_CAT 在促进高级合约和增强比特币脚本语言方面的潜在效用却一直在开发者之间被反复讨论。例如，它在连接堆栈值方面的能力被认为是阻碍某些比特币协议发展的障碍，比如 TumbleBit，如果支持 OP_CAT，其交易大小可以大大减小。

在搜集了 Optech 时事通讯和各种相关内容后，接下来按照时间顺序，整理了一些比特币开发者对 OP_CAT 操作码的讨论。

2019 年

这次「OP_CAT」比特币改进提案（BIP）草案的发起人之一 Ethan Heilman，在 2019 年 10 月就于邮件中表示理解为何它被移除——因为当时脚本面临的情况极为严峻，但他更强调了 OP_CAT 作为一个操作码，其价值不容忽视：「目前想要在比特币基础上构建的多数协议都碰到了一个限制：堆栈值无法被连接。作为一个研究者，如果我遇到这种局限，那么它很可能也在阻碍其他人的进步。如果我可以挥动魔杖重新启用其中一个被禁用的操作码，我会选择 OP_CAT。当然，这将伴随着一个条件：每个串联值的大小必须限制在 64 字节或更少。」

关于 OP_CAT 的讨论，Andrew Poelstra 是一个永远绕不过的人。他在 2021 年 1 月 30 日写了一篇名为《CAT and Schnorr Tricks I》的文章引起了一阵对 OP_CAT 的讨论。Andrew Poelstra 是 Blockstream 研究总监，也是一个资深的比特币密码学脚本编写开发者，在行业内的影响力不言而喻。

在文中，Andrew Poelstra 介绍：「OP_CAT 帮助将堆栈中的两个元素结合起来，并将合并后的结果推回堆栈。这个功能可以用于把多个小元素组装成一个大元素，或者将一个大元素分解成多个小元素。而 CHECKSIGFROMSTACK（CSFS）是一个比特币中从未有过的操作码，它允许用户对任意数据进行签名验证，这与仅能验证交易签名的 CHECKSIG 操作码不同。」

更重要的是，他指出将 OP_CAT 与 CHECKSIGFROMSTACK 结合使用，可以提供一种巧妙的交易内省方法。

注：交易内省是指在比特币脚本中对交易本身的各个组成部分进行检查和分析的能力。简单来说，就是让脚本能够「理解」和处理它正在处理的交易的详细信息，比如检查交易的输出内容、金额或者特定的签名等。这样，脚本就能根据交易的具体内容做出更加智能和细致的响应。

这样用户在堆栈上提供整个交易的数据，脚本利用 OP_CAT 将这些数据打包成一个单一项，进行哈希处理，然后传递给 CHECKSIGFROMSTACK 来验证数据上的签名。接着，它将相同的签名和密钥传递给 CHECKSIG。如果两次验证都通过，表明用户提供的交易数据确实是真实的交易数据。这样，脚本就可以直接利用这些数据执行契约所需的任何检查。

Andrew Poelstra 的影响力，和这篇文章的构思，引起了比特币开发人员的注意，并在那一周的会议，对这种操作码的结合和关于在激活 taproot 后对脚本语言进行微小更改如何提高合约灵活性作出了许多讨论。

距离《CAT and Schnorr Tricks I》的发布过了两周左右的时间，Andrew Poelstra 发了第二篇《CAT and Schnorr Tricks II》，在这篇中，Andrew Poelstra 叙述了更多细节和他的想法：

2019 年 5 月，比特币开发者 Jeremy Rubin 提出了比特币的 CHECKOUTPUTSHASHVERIFY 操作码，目的是为了实施一种基础而有限制的智能合约，避免了之前智能合约设计中的技术和社会风险。这个操作码后续被 SECURETHEBAG 替代，再之后又被 CHECKTEMPLATEVERIFY 取代，而 CHECKTEMPLATEVERIFY 于 2020 年 1 月正式成为比特币改进提案 BIP 0119。

同时，Russell O'Connor 建议直接向比特币添加 CHECKSIGFROMSTACK 和 OP_CAT 操作码，以支持不受鲁宾提案限制的智能合约。尽管该提议遭到了一些反对，并且讨论逐渐减少，主要是由于 CAT+CHECKSIG 类型智能合约效率低下，以及人们对全面通用智能合约持有的长期负面印象。

Andrew Poelstra 一开始也不愿意支持所谓的比特币智能合约功能。然而，在 2019 年秋天，和 Ethan Heilman 的一次私下交流改变了他的想法。Ethan Heilman 指出，尽管存在担忧，但实际上通过 CHECKMULTISIG 就可以实现被认为有害的智能合约，而这类合约由于缺乏认可和可用性，实际上并不被钱包和用户接受。为了证明这一点，Ethan Heilman 在社交媒体上发起挑战，鼓励人们提出可行的「黑暗」智能合约，但至今无人成功。

于是 Andrew Poelstra 转而开始思考，大家对智能合约的恐惧可能被夸大了。文章还提出，即使存在顾虑，智能合约在比特币的发展中是不可避免的，并鼓励继续探索使用非专用操作码 OP_CAT 创建智能合约的可能性。

2021 年

接着是 Jeremy Rubin 于 2021 年 7 月 6 日的一篇文章，从比特币量子安全的角度对 OP_CAT 进行了阐述。Jeremy Rubin 不仅是比特币开发者，也是 Judica 的创始人，这是一家比特币研发组织，专注于开发比特币的智能合约编程语言 Sapio。

在邮件和博客文章中，Jeremy Rubin 讨论了如何利用 OP_CAT 操作码和 Lamport 签名来对比特币进行量子验证。作者首先回顾了之前的一篇博文，讲述了如何利用比特币脚本算术和 Lamport 签名来注册 5 字节值的方法。尽管这个方法整洁，但它有其局限性。Jeremy Rubin 提出了一个想法：如果我们能对更长的信息进行签名会怎样？特别是如果我们能签署至多 20 字节，我们就能签署一个可能是量子安全的 HASH160 摘要。

Jeremy Rubin 在文章进一步探讨了对 HASH160 摘要签名的含义，并解释了即使量子计算机破解了 ECDSA，也只会泄露私钥而不会改变实际签名内容的能力。为此，作者咨询了密码学家 Madars Virza，并得到了肯定的回答。

Jeremy Rubin 指出，如果我们要求 ECDSA 签名使用量子证明签名算法进行签名，我们就能拥有量子证明的比特币。而之前讨论的 5 字节签名方案实际上是一个量子安全的 Lamport 签名。但遗憾的是，这种方法至少需要 20 个连续的字节。

因此，Jeremy Rubin 提出需要某种类似 OP_CAT 的操作。文章说明 OP_CAT 不能直接软分叉到 Segwit v0，因为它会修改堆栈。因此，为了简化，作者展示了如何使用一种新的操作码 OP_SUBSTRINGEQUALVERIFY，该操作码通过验证语义来检查字符串的某个部分是否相等。

2021 年 11 月 5 日，在亚特兰大比特币会议上，Jeremy Rubin 和 Andrew Poelstra 作为演讲人，就在讨论关于重新启用操作码 OP_CAT 的提案，他们认为 OP_CAT 在比特币的上下文中很重要，并强调了它的潜力，特别是在量子安全性和制作复杂智能合约方面。例如，结合 CAT 和 Schnorr 签名验证操作码，理论上可以实现非递归的智能合约。这种智能合约能够将交易数据的 SHA2 哈希直接放入堆栈。通过这样做，可以在某种程度上对交易的各个部分施加限制。

讨论也提到，如果重新引入 CAT，可能会使比特币在某些方面变得复杂的同时也，会引入新的功能和可能性。重启 OP_CAT 需要谨慎考虑，以避免过去出现的问题，如内存爆炸问题。

2022 年

在 2022 年 5 月 18 日的比特币开发者邮件列表中，有关重新引入 2010 年从比特币中移除的 OP_CAT 操作码的讨论中，开发者 ZmnSCPxj 提出，要实现不可避免的递归智能合约，需要将 OP_CAT 与 OP_TX、OP_CHECKSIGFROMSTACK（CSFS）等提议的操作码结合。递归智能合约利用比特币共识规则确保接收到合约的所有比特币只能被花费在相同的合约上。

递归智能合约依赖于事务内省技术，即操作码可以分析执行该操作码的事务的一部分。现有的操作码，提供的都是有限的内省。为了创建递归智能合约，需要确保前一个输出和下一个输出相同。因此，或前一个输出、或下一个输出、或两者都必须从它们的组成元素中动态构造，这就是为什么需要 CAT 或类似结构来实现递归智能合约。

Nadav Ivgi 指出，在创建递归智能合约时，仍然需要 CAT 来解决哈希问题，但这意味着专注于输出内省的 CTV 和 APO 等功能也能够与 CAT 结合创建递归智能合约。Ivgi 认为，在与 taproot 的功能结合使用时，通过下一个输出验证前一个输出可以使智能合约脚本更易于编写，并提供了两个递归智能合约示例的链接。

ZmnSCPxj 同意 Ivgi 的分析，并重申了他对在比特币上启用递归智能合约风险的担忧，尽管他也在后续帖子中指出，递归智能合约可能是安全的，因为它们实际上不是图灵完备的。Russell O』Connor 引用了 Andrew Poelstra 的文章，描述了 CAT 本身如何与已有的比特币功能结合，足以创建非递归智能合约，并且理论上，如果重新添加到比特币中，也可能能够自行创建递归智能合约。

2023 年

1 月，Anthony Towns 推出了 Bitcoin Inquisition，这是一个复刻了 Bitcoin Core 的软件，旨在默认的 signet 上运行，用于测试人们提出的软分叉和其他重大协议变更。截至 2023 年年末，Bitcoin Inquisition 已经支持了多项提案，此外，旨在为 OP_CAT、OP_VAULT 以及限制 64 字节交易的 PR（拉取请求）已经提交到其代码库，预计将进一步扩展这个测试平台的功能。

2023 年 8 月 23 日，在 Lightning-Dev 邮件列表中，Thomas Voegtlin 提出了一个关于过期备份状态的欺诈证明的想法。Voegtlin 指出，如果比特币中以软分叉的方式添加 OP_CHECKSIGFROMSTACK (CSFS) 和 OP_CAT 操作码，就有可能在链上使用这种欺诈证明。该提案引发了大量讨论，Peter Todd 指出基本机制是通用的，不仅限于 LN，可能在各种协议中有用，不过他还提出了一个更简单的机制，在此处就不展开讨论了。

到了 10 月，Rusty Russell 对进行更改的比特币脚本语言的通用智能合约进行了研究。与此同时非常重要的是，Ethan Heilman 和 Armin Sabouri 联合发布了一份 BIP 草案，提议添加 OP_CAT 操作码，该操作码用于将堆栈上的两个元素连接起来。这两个议题的讨论持续到了 11 月。

2024 年

时间来到了 2024 年 1 月，Quantum Cats 确实成功地将关于 OP_CAT 的 BIP 和比特币进程的讨论提升到了一个新的水平。

在和社区的互动中，Bitcoin Core 开发者 Ava Chow 曾表示：「我不认为 CTV 是粗略的共识。我认为实际上其他更一般的智能合约提案更接近，例如 txhash 或 CAT。但是，我没有密切关注讨论。」

按提交次数排序来看，截至目前，Ava Chow（@achow101）在 Bitcoin Core 代码贡献者排名中排名第 5 位，代码提交次数达到 1292 次，也是少数拥有比特币代码合并权之一的人。因此她在开发社区中的影响力也非常大。

「我不是在建议我们激活 OP_CAT。我支持 OP_CAT 因为它是极有可能达成共识的操作码。如果您不了解 OP_CAT 的情况，我在这张图片中总结了这种情况。」因此，Taproot Wizard 的联创 Eric Wall （@ercwl）这么说道。

不过，Ava Chow 似乎对 OP_CAT 的实现并没有表示绝对赞同：「正如我已经说过的，我不认为任何智能合约提案接近或达成粗略的共识。我认为我们不应该尝试激活其中任何一个。」

十行代码，让比特币实现智能合约

正如 Taproot Wizard 的联创 Eric Wall （@ercwl）说道的那样：「人们没有意识到这一点，但 OP_CAT 实际上是比特币上 zkrollup 的构建块之一。」

OP_CAT 的重新引入为比特币提供了一个强大的工具，它可以支持像 BitVM 这样的项目，BitVM 近期推出的概念——在比特币上验证任意计算，将因 OP_CAT 而变得更加简单高效。比特币生态系统能够创建更通用、更富有表现力的智能合约。

通过 OP_CAT，可以实现所谓的智能合约，即为特定比特币输出设定预先规定的条件。这不仅为新的扩展方法，如 Blockstream 的 Ark 等，打开了大门，还支持许多其他依赖于智能合约的创新方法。此外，这标志着比特币不仅仅是一种支付网络，还能成为一个多功能、可扩展的计算平台。

虽然 Taproot Wizard 联创 Eric Wall 对 BitVM 背后的概念感到兴奋，但他认为该提案可能是比特币的「技术死胡同」，因为其开销巨大且实现周期长。他担心 BitVM 可能会分散社区的注意力，阻碍真正的发展。尽管如此，BitVM 的提出仍然表明了区块链技术和智能合约领域的活跃探索和创新精神。

而事实上，Taproot Wizard 项目团队自己也正致力于在比特币上实现第二层解决方案，在此前的一次 Space 中，他们也表示完成的 750 万美元融资，将会用于研究比特币扩容方案。

因此 OP_CAT 的软分叉，对他们来说也将是重要的一步。Eric Wall 曾经是 StarkNet 基金会的董事会成员，他对创建无需许可的结算层上构建去中心化金融有着极大的兴趣，因此当以太坊在 2019 年开始出现时，他自然而然地被以太坊上的 DeFi 领域所吸引。

当在 2019 年明显地发现以太坊和其他区块链可以通过使用 zk-Rollups 或乐观欺诈证明来扩展时，比特币在 DeFi 方面的探索几乎已被完全放弃。带着「zk-Rollup 扩容应用于比特币的可行性」等问题的研究，Wall 转向支持以太坊上的 DeFi。但终将，他正在努力试图将这个系统和这些技术优势引入比特币。

此外，在 bitcointalk 论坛中关于 OP_CAT 的讨论帖中，QED 项目的创始人 Carter Feldman（@cmpeq）被问及将打算如何在比特币脚本中利用这一操作码，以及他是否计算了见证堆栈的平均字节数以及可能产生的费用时。

Carter Feldman 表示已经认识到这可能会有点昂贵，但他解释说，默克尔证明在他的项目中主要用于构建一个无信任的锁定脚本或挂钩系统，作为比特币上 zk 第二层的一部分。这一系统旨在证明在给定的提款树根（作为零知识证明的公开输入）的情况下，可以向特定地址提取一定数量的比特币。

为了解决成本问题，他提到这将是一个手段。他设想，普通用户可以通过让包装 BTC 的卖家在 L2 上锁定他们的代币一段时间来购买第二层上的包装 BTC，在这段时间内，买家必须证明他们已经在比特币 L1 上向卖家支付。他们知道，如果愿意，他们总是可以无信任地换回比特币。同时，几个大型流动性提供商会成为实际在 wBTC 和 BTC 之间进行交换的主体，并可能向那些想要从他们那里购买 wBTC 或将其桥接回比特币的小型用户收取小额费用。

因此总的来说，OP_CAT 的这次 BIP 提案仅用 13 行代码，就能帮助在比特币上构建智能合约，但至于具体到每个项目处理细节上，仍将会有大量的讨论和尝试的方案。

模因文化造势技术推进

TaprootWizards 团队成员 Rijndael（@rot13maxi）在社交媒体上分享了他们为了创造艺术品而使用的各种复杂机制。为了达成这一目标，他们依赖于多种技术，包括序数递归、预签名交易、对称密码学和客户端负载管理。在艺术创作的过程中，他们特别选择使用预签名的交易来执行操作，展示了如何使用 OP_CAT 或 CTV 等智能合约预先提交交易的哈希值。

但 Armin Sabouri 对此发表了富有讽刺意味的评论：「在创建一个不断发展的 NFT 集合方面，所投入的代码和技术努力可能是重新启用某个操作码所需工作量的 100 倍。」

OP_CAT 被认为是一个简单易懂的操作码，有观点认为它可以通过签名 ECDSA 签名使比特币成为「量子安全」。这一观点得到了一些人的支持，并激发了 Taproot Wizard 推出 Quantum Cats 量子猫 NFT 的宣传活动，通过这些活动来提高对 OP_CAT 的认识。

然而，用模因文化为技术推进而造势的，不只是 OP_CAT 一个。

受 Quantum Cats 及其 0.1BTC 的售价的启发，以及或许是带着部分对其高额售价的不满情绪，OP_CTV 社区也推出了一个名为 #rubinsreubens 的三明治模因，以宣传 OP_CTV 的技术。

这个三明治模因起初是作为对量子猫及其模因的一种幽默回应。然而，它实际上非常有效，因为与 CTV 一样，它添加了层次结构，你可以根据需要在「sammich」上制作任意数量的层次。

这个三明治模因吸引了许多人的注意。模因是有趣的，可以用来表示对某事的支持，但理解其背后的含义也很重要。#rubinsreubens 的目的在于提高人们对 op_ctv、lnhance 以及新的 BTC 操作码和启用智能合约的软分叉提案的理解。

OP_CAT 失败的潜在原因

回到 OP_CAT 上来，人们可能会出于多种原因反对引入像 OP_CAT 这样的功能。首先，增加新的操作码或特性如 OP_CAT 可能会提高比特币的复杂性，从而使其更难以理解和安全使用，增加了风险。其次，引入新功能时的安全问题也不容忽视，未经充分测试的特性可能藏有漏洞，损害比特币的整体安全性。此外，软分叉的升级如果没有被所有节点采纳，可能会导致网络分裂，造成不同版本的比特币网络共存，使达成共识变得更加复杂。

新特性可能带来兼容性问题，特别是如果它们不支持旧版节点，可能会将一些节点排除在网络之外，对比特币的生态系统产生负面影响。特别是对于那些没有升级的用户，他们可能会发现自己无法继续参与网络。此外，有些人可能认为引入新功能是匆忙的决定，而没有优先考虑解决比特币核心协议中的紧迫问题。匆忙的变更可能引入不必要的风险和不稳定性。

除了对安全和风险的考虑，OP_CAT 将失败的两个很大原因是：比特币社区对智能合约的恐惧、比特币智能合约没有「正统性」。

对智能合约的恐惧

对比特币智能合约的恐惧可能是实现 OP_CAT 遭遇的另一个重要障碍。智能合约作为区块链技术的一个核心组成部分，在许多区块链项目中发挥着至关重要的作用，尤其是在以太坊等平台上。

然而，在比特币社区中，智能合约的接受程度相对较低，这部分是由于对智能合约可能带来的风险和挑战的担忧。智能合约可能会影响比特币的核心价值观，例如点对点、去中心化和安全性。比特币社区对保持这些核心价值观非常重视，任何被认为威胁到这些价值观的改变都可能遭到反对。

智能合约的一个主要担忧是它们可能会增加整个网络的复杂性和安全性风险。智能合约往往涉及复杂的逻辑和代码，任何小小的错误或漏洞都可能导致严重的安全问题，甚至可能导致大规模的资金损失，正如过去在某些区块链项目中所发生的那样。此外，智能合约的引入可能会使整个系统更难以理解和审核，从而增加出错的可能性。

此外，比特币社区一直非常重视保持网络的稳定性和安全性。比特币的设计哲学倾向于简洁和保守，优先考虑网络的安全性和去中心化。因此，任何可能对网络稳定性构成威胁的重大更改都会受到严格的审查和广泛的辩论。OP_CAT 和智能合约的引入，尽管可以为比特币带来新的功能和可能性，但也可能会被视为与比特币的原始愿景和设计哲学背道而驰。

中本聪「错」了？

恢复 OP_CAT 操作码在社区中引发了深刻的讨论，部分原因是它触及了一个敏感的议题：这是否意味着中本聪错了？

作为比特币的创始人，中本聪的决策和原始设计被许多人奉为圣经，他的原始愿景被认为是比特币发展的核心指南。因此，对中本聪的决策进行任何形式的挑战或修改，都可能被视为对其遗产的不尊重，或者是对比特币核心原则的背离。毕竟在区块链行业里，正统性始终都是一个绕不过去的话题。

因此，恢复 OP_CAT 的提案也触及了一个更广泛的问题：比特币应该是一个静态的实体，还是应该适应不断变化的技术环境和用户需求？

然而，技术领域总是在不断进步和变化之中，比特币作为一种技术创新，也不可能完全摆脱这一规律，显然支持恢复 OP_CAT 的 Taproot Wizard 团队正是这么想的。毕竟他们曾有意设计出了有史以来较大的比特币区块，略低于比特币 4MB 限制的方式，来发布 NFT Taproot Wizards。

Taproot Wizard 创始人 Udi Wertheimer 表示，他明白很多人认为比特币不应该变化。他认为，比特币的变化应该是缓慢的、谨慎的、深思熟虑的。他认为比特币还太年轻，还不能完全固化，并指出治理过程在某种程度上是破碎的。尽管技术社区普遍认同比特币将会有更多的升级，但确实很难确定具体会有哪些升级。尽管如此，Wertheimer 强调改变是必要的，因为当前的比特币还无法为数十亿人提供服务。

当然，这样的改变也伴随着风险和挑战，如安全性问题、网络分裂风险、兼容性问题等，这些都需要被慎重考虑和解决。

可以预见的是，接下来，为了确保提议的改进安全有效，将 OP_CAT 部署在测试网络环境中是至关重要的步骤，允许开发者在不影响主网络的前提下发现并解决问题。

同时，这想要真正实现 OP_CAT 的「重启」，整个过程将会持续相当长一段时间，甚至以年为计算单位，因为它涉及到多方面的考虑和平衡，包括技术细节、社区共识、以及对比特币网络安全和稳定性的考量，以及非常重要的，得到广泛的社区支持和认可。