文章精简摘要： 「恢复 OP_CAT」是一个严重误解，提案中有一段重要的话为证：This implementation is inspired by the original implementation of OP_CAT as it existed in the Bitcoin codebase prior to the commit "misc changes" 4bd188c which disabled it: 比特币亚洲大会上讨论了一个技术相关话题，在比特币的脚本语言中要不要恢复 OP_CAT 操作指令？之后在万物岛 BTC 工作室的上海闭门会议中，大山老师也讨论了相关的问题，鼓励我们工作室的学员来写一篇系统的总结文章。 为什么一个指令的恢复会在业内大会上讨论？它有那么大的重要性吗？这个事情涉及到了哪些问题？相信很多人会有相关的疑问。 1. OP_CAT 的基础知识 要了解恢复 OP_CAT 这个问题，我们先了解一些和 OP_CAT 相关的基础知识。在开发语言中，操作码（opcodes）也会称为指令或函数，是构成开发语言的基本组成元素。在本文中我们都称为指令。 1.1. OP_CAT 具有什么功能？ 在很多开发语言中，连接两个字符串一般多用 concat，所以 OP_CAT 的缩写也应该是来自 concat 这个单词，形成 OP_CAT 的指令。 例 1：java 开发语言中的 concat String str1 = "Hello"; String str2 = " world"; // 注意有空格 String str3 = str1.concat(str2); System.out.println(str3); 输出结果就是 Hello world 例 2：mysql 中的 concat select CONCAT（"My","SQL"）from Result；执行结果就是显示「MySQL」这几个字符。 在高级开发语言中，concat（即字符串拼接）的使用频率非常高，而且在很多情况下也非常重要。例如一些场景： 数据展示与输出：在很多场景下，我们需要将数据以字符串的形式进行展示或输出，比如将不同的数据项连接成一个完整的句子、将数据格式化成特定的字符串形式等等，这时候就需要使用字符串拼接操作。 数据处理与操作：在数据处理与操作中，有时候需要将多个字符串进行拼接以生成新的字符串，比如将多个文件路径拼接成一个完整的路径、将多个 URL 参数拼接成一个完整的 URL 等等，这也是字符串拼接操作的重要应用。 如果比特币的语言是高级语言，毋庸置疑一定会有这个字符连接功能，但比特币的开发语言有些特殊性，所以产生了是否要包含这个指令的争议。比特币的语言是一种逆波兰范式的脚本语言，它是非图灵完备的。比特币脚本指令常见的类型： 关键字： 1. 常数。如：OP_0，OP_FALSE 2. 流程控制。如： OP_IF，OP_NOTIF，OP_ELSE，…… 3. 堆栈。如：OP_TOALTSTACK（把输入压入辅堆栈的项部，从主堆栈删除），…… 4. 字符串。如：OP_CAT（连接两个字符串，已禁用），OP_SIZE（把栈顶元素的字符串长度压入堆栈（无需弹出元素）） 5. 位逻辑。如：OP_AND，OP_OR，OP_XOR 6. 算术逻辑。如：OP_1ADD（输入值加 1），OP_1SUB（输入值减 1） 7. 加密。如：OP_SHA1（输入用 SHA-1 算法 HASH.），OP_CHECKSIG（） 8. 伪关键字 9. 保留关键字 比特币脚本指令常见的类型： 脚本： 1. 支付到比特币地址的标准交易（pay-to-pubkey-hash） 2. 标准比特币产生交易（pay-to-pubkey） 3. 可证明的无法花掉 / 可删除的输出 4. Anyone-Can-Spend 输出 5. 猜谜交易 五个标准类型的交易脚本包括：支付到公钥哈希（P2PKH）、支付到公钥、多重签名（限定最多 15 个密钥）、支付到脚本哈希（P2SH），以及数据输出（OP_RETURN）。 在网址：https://en.bitcoin.it/wiki/Script 中有详细的说明。 1.2. 比特币语言中删除 OP_CAT 与其他指令的删减 其实在早期比特币的脚本语言中也是有字符连接的功能的，也就是「OP_CAT」操作码开始是存在的，后来被删除了。在比特币的脚本语言中，OP_CAT 可以实现多个 UTXO 解锁脚本字节串的组合连接处理，可以提升 BTC 主网的可编程特性和计算的复杂性。但由于中本聪对于安全的考虑（也有可能是对稳定性的考虑），在 2010 年 8 月，这个操作码被移出比特币协议。 在比特币的脚本语言中，开始和字符操作相关的指令有很多，在之后大部分都被删除了，删除了 OP_CAT、OP_SUBSTR、OP_LEFT、OP_RIGHT，只保留了 OP_SIZE。如下图所示。 不仅删除了字符串操作指令，还删除了不少其他指令。 （1）位操作相关指令 （2）算术操作 为什么要删减这么多指令？关于比特币技术发展变化的详细内容，读者可以阅读《导致比特币再次爆发的新技术发展总结》。 2. 为什么有人要「恢复 OP_CAT」 网上很多人都在说比特币要「恢复 OP_CAT」，这是众人对这个事情的一个严重的误解。但确实需要 OP_CAT 那样的字符连接功能，是要在 Tapscript 中增加这个类似功能，于是要产生「恢复 OP_CAT」这件事情。 2.1. 「恢复 OP_CAT」的提案与众人的误解 在介绍相关内容前，我们需要先对 BIP 有所了解。BIP 是 Bitcoin Improvement Proposal 的缩写，直接翻译为：比特币改进提案。包含以下几种状态，他们之间的状态转换如下图所示： 2023 年 10 月，Bitcoin Core 开发者 Ethan Heilman 和 Botanix Labs 首席软件工程师 Armin Sabouri 联合推出了一份比特币改进提案（BIP）草案，名为「OP_CAT」，让这个讨论到了一个新的高度。详细提案内容查看网址：https://github.com/bip420/bip420 Tapscript 提案的新脚本（12 行）如下 提案中还有一段重要的话：This implementation is inspired by the original implementation of OP_CAT as it existed in the Bitcoin codebase prior to the commit "misc changes" 4bd188c which disabled it: 参考的原有比特币脚本代码（13 行）如下： BIP420 这份草案，仅包含简洁的 12 行程序代码（与原来的 BTCscript 很相似），却携带了明确直观的功能性质，定义了一个新的 Tapscript 操作码，允许在堆栈上连接两个值。此操作码实现的灵感明显来自原始被删除的 OP_CAT。这段文字被我用不同的颜色来标识，在强调不是在比特币的原始指令中恢复相关指令，而是在 Taproot 的扩展中 Tapscript 中重新实现一个类似指令。 在比特币的指令中恢复某些指令和在 Tapscript 中产生新指令是不同的概念，有不同的影响范围。 2.2. 哪些功能或应用需要恢复 OP_CAT 完全理解这个问题需要两部分知识： （1）在 1.1 节中，我们已经知道在编程语言中字符连接 concat 是一个非常常见与重要的功能，在高级开发语言或者功能丰富一些的编程语言中都需要这个功能。有了这个共识，再了解到比特币的变化，就会理解恢复 OP_CAT 的根本原因。 当前一些想在比特币主网上面开发功能的团队与项目方很希望恢复这个指令。有了这个指令，可以实现功能更强大的智能合约（比特币上有智能合约，只是不是图灵完备的）。这个功能的添加，会支持许多其他依赖于智能合约的创新方法，还可以把比特币从仅为支付服务的网络，发展成一个更多功能、可扩展的计算平台。 （2）比特币已经通过 Taproot 为扩展功能做好了准备。在这里我们需要详细的了解一些知识：Taproot、MAST、Taproot Scripts。最好阅读《导致比特币再次爆发的新技术发展总结》，了解比特币技术爆发的底层变化。 比特币技术通过隔离见证 Segwit 扩充了比特币的 OP_RETURN 的功能，使得比特币可存储的实际空间直接扩大，区块最大可以到达 4M。这些扩大出来的空间，当前被人们大量的使用在存储文本或图片等场景，但设计者的目的是用于扩展比特币的功能。因为为了扩展功能产生的几个 BIP 协议 BIP340、BIP341 和 BIP342，其中 BIP340 引入了可以同时验证多个交易的 Schnorr 签名，取代了椭圆曲线数字签名算法（ECDSA），再一次扩大了网络容量并加快了批量交易的处理速度，为部署复杂的智能合约提供了可能性；BIP341 实现了默克尔化抽象语法树（MAST）来优化区块链上的交易数据存储；BIP342（Tapscript）采用比特币的脚本编码语言扩充的比特币原生脚本能力的不足。 由隔离见证 Segwit 与 Taproot 的空间扩大，导致了 Schnorr、MAST 树和 TapScripts 的产生，他们要完成的使命是比特币主网的功能扩大。4M 的存储空间可以存储大量的程序代码，只要 Tapscript 的功能足够强大，就能开发出非常多的应用。但当前 Tapscript 刚刚诞生，很多指令还不够完善，会出现逐步扩大 Tapscript 指令功能的情况。 3. 比特币协议在 Web3.0 中的地位与作用 即使通过第 2 节我们了解到了恢复 OP_CAT 的提案内容与原因，那我们怎么评判这类事件？因为不光要增加 OP_CAT，Tapscript 还会增加其他指令，那掌握这个增加的基本原则有哪些呢？我们还需要从更宏观的角度来看待比特币。 3.1. Web3.0 的应用架构与分层协议设计思想 在《从状态机的角度观察比特币二层，可以看到未来 Web3.0 应用的架构和建设路径》文章中，我们已经大致勾画出 Web3.0 的应用架构，如下图所示： 我们可以看到区块链是 Web3.0 中重要的基础设施，并且只有比特币网络适合作为分层结构中的最底层基础设施。这就是为什么说区块链是「以比特币为开局，以比特币生态为终局」，所有的其他区块链系统都是比特币的广义二层或测试技术。 了解了 Web3.0 的应用架构，我们还需要理解一些分层设计思想（尤其是底层应该具有的特征）。分层设计是一种人类处理复杂系统的手段和方法论，通过将系统划分为多个层次结构并定义各层之间的关系和功能，以实现系统的模块化、可维护性和可扩展性，从而提高系统的设计效率和可靠性。我们使用已有的案例来说明，如下图的 TCP/IP 协议： 在协议的底层，TCP 协议与 IP 协议只需要实现最简单，最基础的功能，那些应用层的协议，如 FTP、SMTP、IMAP、HTTP 等协议都在高层来实现，会封装在 TCP 协议和 IP 协议中。 如果比特币是类似 TCP/IP 协议的最底层协议，那么比特币主网原则上也要保持最简单，最基础的功能。那些丰富的功能，尤其是应用层的功能都需要在比特币的二层或三层协议上来实现。有了这个原则，我们会对明确的底层协议与上层协议有准确的判断，那么像 Tapscript 这样在比特币主网上实现的扩展功能，我们该怎么判断呢？ 3.2. 过度设计与够用即可的两种做事哲学思想 为了增加我们的判断准确性，我们先了解两种做事的哲学思想：过度设计和够用即可。（也许我们知道了也没有用，因为比特币的发展决策是很多因素决定的，比特币的去中心化文化使得它的发展会由很多因素决定，或者是由人类的群体思想决定。） 过度设计和够用即可是两种不同的做事哲学思想，它们各自有不同的优缺点。以下是它们的优缺点和一些例子： （1）过度设计 过度设计的优点：

• 可扩展性强：过度设计通常考虑了未来的需求变化，能够应对各种扩展和改变。
• 更具灵活性：过度设计的系统能够适应各种不同的情况和需求，具备更高的灵活性。
• 提高长期效率：很多功能可以在后期之间调用底层来开发，长期上看效率是提高的。

过度设计的缺点：

• 耗时：过度设计需要更多的时间和资源来完成，可能会导致项目延期。
• 资源浪费：过度设计可能会引入冗余的功能或复杂的结构，浪费了资源。
• 可能过于复杂：过度设计可能导致系统结构过于复杂，增加了系统维护和理解的难度。

过度设计适用场景（我个人的一些经验总结和参考 ChatGPT 的部分内容）： 过度设计通常适用于非全新的项目，有可以参考的例子，并且全新案例的初始需求比较少或不够明确，但预计需求变化可能会比较频繁，就可以借鉴已有的经验，在一定程度上使用过度设计的原则。例如，大型软件系统或平台的底层可以考虑过度设计。 （2）够用即可 够用即可的优点：

• 简单明了：够用即可的思想注重解决当前需求，使系统保持简单和易于理解。
• 资源节约：够用即可的思想避免了过度设计和不必要的功能，节约了时间和资源。
• 快速交付：够用即可的思想可以快速交付可用的产品或系统，满足用户的基本需求。

够用即可的缺点：

• 无法适应变化：够用即可的思想可能无法适应未来的需求变化，需要进行较大的修改和调整。
• 可扩展性差：够用即可的思想可能导致系统缺乏可扩展性，难以添加新功能和组件。

够用即可的适用场景：要实施的项目没有可以参考的样例，或可参考的样例很少，不知道发展的方向和目的地，可以采用够用即可的方式。还有那些小型项目完全适用够用即可的思想。对于创新性项目，很多时候也会采用这种原则，因为未来完全不明确。 过度设计和够用即可并不是对立的概念，而是一种思维方式的不同取向。在比特币的原生脚本 BTCscript 上多数采用够用即可原则，但 Tapscript 是一种原生脚步的扩展，可以参考一些编程场景，稍微过度设计一些。在 Taproot 和 Tapscript 的使用上也需要考虑，它们只是一层与二层之间的连接技术，不应该过度使用，甚至要限制在 Tapscript 上面的功能。这样我们就找到了设计 Tapscript 的下限与上限。 3.3. Web3.0（下一代互联网）的辉煌未来 在 3.2 节中我们表达了在 Tapscript 的指令设计上可以适当的过度设计，但上限是满足连接比特币一层和二层的需求即可。但在早期，尤其是比特币价格还不过高的情况下（每次简单交易执行不超过 100 美元，都被认为不过高）和分布式系统的二层或三层还不成熟的情况下，很多人还是会开发过多的功能，这导致 Tapscript 也可能会包含过多的指令。 从另一方面，区块链技术与相关的分层建设作为整个 Web3.0 的基础设施来看，比特币的 Tapscript 技术也不应该开发过多的功能。参考 3.1 节中的 Web3.0 的应用架构图。 在《从状态机的角度观察比特币二层，可以看到未来 Web3.0 应用的架构和建设路径》我们通过中国互联⽹络发展状况统计报告了解 Web2.0 的丰富应用。在统计报告中，可以看到 Web2.0 中的应用已经非常丰富，并且拥有巨大的用户群体。这些应用包括：即时通讯、网络视频、短视频、网络支付、网络购物、搜索引擎、网络新闻、网络音乐、网络直播、网络游戏、网上外卖、网络文学、网约车、在线办公、在线旅行预定、在线教育、在线医疗、……，几乎覆盖了人们生活的全部领域。除了这些消费互联网的内容，在产业互联网中也有很多的应用。 各类互联网应用用户规模和网民使用率 这些主流应用都还没有进入到 Web3.0 的世界。当这些应用进入 Web3.0 时代后，用户的规模和性能要求更高。所以比特币主网承担的任务在未来是非常重，使得一定要用分层结构才能建立起来真正的 Web3.0 世界。那么在比特币主网上面的功能就以简单稳定为主，以服务一层与二层的连接技术为主。我个人主张不要过度使用比特币一层与二层的连接技术，给 Tapscript 一个扩展空间，但不要有太多的功能。 4. 是否恢复 OP_CAT 谁有决定权 通过前面的内容，我们知道了这个提案的真实内容，是在 Tapscript 中产生一个类似 OP_CAT 的指令功能，而不是恢复比特币脚本中原来的 OP_CAT。对于这个提案谁有决策权呢？比特币 Core 的开发团队？矿工？生态开发者？社区？ 如果我们从利益的角度分析，Tapscript 中产生 OP_CAT 指令会增加比特币主网的可编程性，会产生更多的比特币主网程序和应用，这样就会增加主网上面的手续费。矿工会是最积极的支持者，生态开发者因为增加了开发的可能性也会支持。 比特币 Core 团队怎么考虑？一直以来 Core 团队秉持一种保守风格，会不会同意呢？有很大的不确定性。其实这个事件还牵扯出一个较大问题，对于 Tapscript 的发展，需要制定一套规则，它不同于比特币主网的 BTCScript，决策上是否也要适当宽松一些？比特币的 BIP 协议参考以太坊的 EIP 协议，作一下提案的分级也许是个不错的方法。对每种提案采用不同的审核标准。 通过整理这篇文章，我个人判断这个提案最终会获得通过，不然 Tapscript 的功能就太弱了，也许过程会有些曲折。 在比特币的世界，因为没有权威机构，权利在比特币的世界不是直接影响因素，只有经济因素才会是决定性的影响因素，什么会获得通过最终是由大多数人的利益驱动的。即使 Tapscript 被过度设计了，在使用中也会被经济因素矫正过来。