比特币最初的设计理念包含了一套完整的脚本语言系统，旨在为用户提供应对各种潜在安全需求的灵活性。中本聪在2010年6月17日的发言中清晰地阐述了这一设计哲学：”比特币的核心架构在0.1版本发布后就已定型，因此我们需要构建一个能够适应各种交易类型的通用系统。脚本语言的引入正是为了解决特殊用例爆炸式增长的问题，它允许交易双方通过节点网络可评估的谓词来描述交易。”
这种设计初衷是赋予用户足够的自由度，让他们能够自主设计和实验资金的管理方式。然而在中本聪离开前，他不得不禁用15个操作码，并设置了520字节的堆栈数据限制。这并非因为这些功能本身存在危险，而是由于当时缺乏有效的资源限制机制，可能导致恶意用户创建验证成本极高的交易来攻击网络。
多年来，比特币的升级过程始终围绕着简化功能、修复缺陷和扩展现有脚本能力展开。直到2021年Taproot激活后，开发者社区开始意识到需要更系统性地解决比特币的可扩展性问题。Core Lightning开发者Rusty Russell在今年五月的Austin Bitcoin++会议上提出了一个大胆建议：重新启用大部分被禁用的操作码。
当前比特币面临的核心挑战在于基础层功能的局限性制约了Layer 2解决方案的发展。闪电网络就曾需要三个独立的软分叉才能实现。要构建更灵活的Layer 2方案，我们需要在基础层实现更强大的功能，特别是契约（covenants）机制，使得脚本能够对交易进行更精细的控制，确保多人共享UTXO时的资金安全。
具体而言，我们需要三个关键功能：内省能力，用于检查交易细节；正向数据传递，用于跟踪多人资金分配；以及公钥修改功能，用于验证聚合公钥的变更。这些功能都需要通过恢复和扩展脚本操作码来实现。
关于安全性问题，可以借鉴Taproot的签名操作预算机制，为每个重新启用的操作码分配验证成本限制。这种”varops限制”方案能够有效防范拒绝服务攻击，解决中本聪当年面临的网络安全顾虑。
这项提案的真正价值不在于是否要全盘接受所有操作码，而在于它提供了一个全面审视比特币未来发展方向的契机。通过系统评估这些原始功能，开发者社区可以达成更清晰的共识，避免过去几年在零散功能改进上的无谓争论。无论最终选择哪些功能进行恢复，这个过程都将帮助比特币生态找到更明确的前进道路。
拟恢复的操作码功能
- OP_CAT：将栈中两个数据合并
- OP_SUBSTR：按指定长度截取数据
- OP_LEFT/OP_RIGHT：从数据左右侧截取
- 位运算操作码：包括OP_INVERT、OP_AND等
- 数学运算操作码：如OP_MUL、OP_DIV等
- OP_CTV：强制交易符合预设模板
- CSFS：验证任意数据签名
- OP_TWEAKVERIFY：验证Schnorr公钥操作
这项提案标志着比特币发展历程中的一个重要转折点。它既是对原始设计理念的重新审视，也是面向未来挑战的系统性思考。通过这样的全面评估，比特币社区有望找到平衡创新与安全的可持续发展路径。
声明：文章不代表CHAINTT观点及立场，不构成本平台任何投资建议。投资决策需建立在独立思考之上，本文内容仅供参考，风险 自担！转载请注明出处：https://www.chaintt.cn/14232.html
