中本聪错了？13行程式码“OP_CAT 软分叉”如何让比特币实现智能合约

点击蓝字 关注我们

✦

✦

OP_CAT 这函式曾一度被中本聪从比特币指令语言中移除，但如今有一些比特币开发者想要复活它，并通过 13 行程式码的软分叉，为比特币添加入智能合约功能。

文章来源 Block Beats

本文目录

1. “复活”被中本聪删除的操作码

2.“复活”的条件已经满足

3.软分叉，谈何容易

4. 比特币开发者们怎么说

4.1.2019 年

4.2.2021 年

4.3.22022 年

4.4.2023 年

4.5.2024 年

5.十行程式码，让比特币实现智能合约

6. 模因文化造势技术推进

7.OP_CAT 失败的潜在原因

8.对智能合约的恐惧

9. 中本聪“错”了？

比特币程式码库中，一个曾经被中本聪删除、被历史尘封已久的操作码“OP_CAT”或将复活。围绕着OP_CAT操作码，比特币NFT专案 Taproot Wizards 推出了新系列 NFT Quantum Cats 引起社群热议。

尽管OP_CAT这一称呼并非指向我们熟悉的“猫”，但 Taproot Wizard 却用了猫的形象发售了一款名为Quantum Cats的新 NFT，利用迷因文化，帮助OP_CAT造势。

在比特币开发者的推动和以猫的模因形象造势下，关于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 的表达力和功能。例如，它可以用于构建和评估默克尔树和其他 hash 资料结构，支援树签名、后量子 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 将这些资料打包成一个单一项，进行 hash 处理，然后传递给 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 hash直接放入堆迭。通过这样做，可以在某种程度上对交易的各个部分施加限制。

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

2022 年

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

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

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

ZmnSCPxj 同意 Ivgi 的分析，并重申了他对在比特币上启用递迴智能合约风险的担忧，儘管他也在后续帖子中指出，递迴智能合约可能是安全的，因为它们实际上不是图灵完备的。

Russell O’Connor 引用了 Andrew Poelstra 的文章，描述了 CAT 本身如何与已有的比特币功能结合，足以建立非递迴智能合约，并且理论上，如果重新新增到比特币中，也可能能够自行建立递回智能合约。

2023 年

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 位，程式码提交次数达到 1,292 次，也是少数拥有比特币程式码合并权之一的人。因此她在开发社群中的影响力也非常大。

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

不过， 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 等智能合约预先提交交易的 hash 值。

但 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 的“重启”，整个过程将会持续相当长一段时间，甚至以年为计算单位，因为它涉及到多方面的考虑和平衡，包括技术细节、社群共识、以及对比特币网路安全和稳定性的考量，以及非常重要的，得到广泛社群支持和认可。

往期推荐

点赞  分享  在看

点一下    给小编 💕 加个油